Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-24976

CVE-2025-24976: Distribution Registry Auth Bypass Vulnerability

CVE-2025-24976 is an authentication bypass flaw in Distribution registry versions 3.0.0-beta.1 through 3.0.0-rc.2 that allows attackers to inject untrusted signing keys in JWTs. This article covers technical details, affected versions, impact, and mitigation strategies.

Published:

CVE-2025-24976 Overview

CVE-2025-24976 affects Distribution, the open-source toolkit used to pack, ship, store, and deliver container content. Registry versions 3.0.0-beta.1 through 3.0.0-rc.2 with token authentication enabled are vulnerable to a JSON Web Token (JWT) signing key injection flaw. An attacker can supply an untrusted JSON Web Key (JWK) in a JWT header. The verification code checks whether the KeyID (kid) matches a trusted key but fails to confirm that the submitted key material matches. This authorization flaw is classified under CWE-639 and can allow attackers to forge tokens accepted by the registry.

Critical Impact

Attackers with knowledge of a trusted key ID can forge valid JWTs and bypass token authentication in affected Distribution registry deployments.

Affected Products

  • Distribution registry version 3.0.0-beta.1
  • Distribution registry versions 3.0.0-rc.1 through 3.0.0-rc.2
  • Any deployment of the affected versions with token authentication enabled

Discovery Timeline

  • 2025-02-11 - CVE-2025-24976 published to the National Vulnerability Database
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-24976

Vulnerability Analysis

Distribution's token authentication module accepts JWTs that embed a JWK header. When the JWK does not include an accompanying X.509 certificate chain, the registry is expected to treat the key as trusted only if it appears in the pre-configured trusted key set. The vulnerable code performs a lookup by KeyID (kid) alone. It never compares the presented key material with the trusted key material stored under that identifier. An attacker who knows or guesses a valid kid can craft a JWT signed by an attacker-controlled key, embed the matching public key in the JWK header, and pass verification.

Because registry tokens gate push, pull, and delete operations, successful forgery can lead to unauthorized access to container images. The flaw does not require prior authentication and is exploitable across the network wherever the registry token endpoint is reachable.

Root Cause

The root cause is an incomplete trust check in registry/auth/token/token.go. The verification routine confirmed the presence of the kid in the trusted-keys map but returned without substituting the trusted key material for use in signature validation. The signature was therefore verified against the attacker-supplied JWK rather than the registry's trusted key.

Attack Vector

Exploitation is remote and unauthenticated. An attacker sends a crafted JWT to the registry's token-protected endpoints. The JWT header contains a JWK whose kid matches a known trusted key identifier, but with attacker-generated key material. Because the registry validates the signature using the injected JWK, the forged token is accepted and access is granted according to the claims the attacker chose to embed.

go
// Security patch in registry/auth/token/token.go
// Fix registry token authentication bug
 	// Check to see if the key includes a certificate chain.
 	if len(jwk.Certificates) == 0 {
 		// The JWK should be one of the trusted root keys.
-		if _, trusted := verifyOpts.TrustedKeys[jwk.KeyID]; !trusted {
+		trustedKey, trusted := verifyOpts.TrustedKeys[jwk.KeyID]
+		if !trusted {
 			return nil, errors.New("untrusted JWK with no certificate chain")
 		}
 		// The JWK is one of the trusted keys.
-		return
+		return trustedKey, nil
 	}
 
 	opts := x509.VerifyOptions{

Source: GitHub commit f4a500c. The patch returns trustedKey so that subsequent signature verification uses the configured key material rather than the attacker-supplied JWK.

Detection Methods for CVE-2025-24976

Indicators of Compromise

  • Registry access logs showing successful token-authenticated requests from unexpected client IPs or user agents.
  • JWT bearer tokens presented to the registry that contain a jwk header instead of, or alongside, an x5c certificate chain.
  • Unexpected image push, pull, or delete operations attributed to accounts that did not initiate them.

Detection Strategies

  • Inspect incoming JWTs at the registry proxy layer and flag tokens whose header includes a jwk field without a matching x5c chain.
  • Correlate token issuer, kid, and resulting registry actions to identify tokens that appear valid but do not match issued token records held by the auth service.
  • Compare the running registry binary version against the fixed release (3.0.0-rc.3 or later) as part of continuous configuration monitoring.

Monitoring Recommendations

  • Enable verbose auth logging on the Distribution registry and forward logs to a centralized analytics platform for anomaly detection.
  • Alert on repository writes performed outside of expected CI/CD service accounts or IP ranges.
  • Monitor for repeated 401 responses followed by a successful 200 from the same client, which can indicate token forgery attempts.

How to Mitigate CVE-2025-24976

Immediate Actions Required

  • Upgrade Distribution registry to version 3.0.0-rc.3 or later, which contains commit 5ea9aa028db65ca5665f6af2c20ecf9dc34e5fcd.
  • Rotate any trusted signing keys and revoke previously issued tokens if compromise is suspected.
  • Audit registry access logs for unexpected push, pull, or delete operations since the vulnerable version was deployed.

Patch Information

The fix is available in commit 5ea9aa028db65ca5665f6af2c20ecf9dc34e5fcd and ships in Distribution 3.0.0-rc.3. Details are provided in the GitHub Security Advisory GHSA-phw4-mc57-4hwc and the patch commit.

Workarounds

  • No configuration-based workaround exists for deployments that require token authentication; patching is the only remediation path.
  • Where feasible, temporarily disable the token authentication backend and restrict registry access via network controls until the upgrade is applied.
  • Restrict network exposure of the registry to trusted CI/CD networks while the patch is being rolled out.
bash
# Verify installed Distribution registry version
registry --version

# Pull the fixed image tag once available and redeploy
docker pull distribution/distribution:3.0.0-rc.3
docker stop registry && docker rm registry
docker run -d --name registry \
  -p 5000:5000 \
  -v /opt/registry/config.yml:/etc/docker/registry/config.yml \
  distribution/distribution:3.0.0-rc.3

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.