Security
Headlines
HeadlinesLatestCVEs

Headline

GHSA-phw4-mc57-4hwc: Distribution's token authentication allows to inject an untrusted signing key in a JWT

Impact

Systems running registry version > 3.0.0-beta.1 with token authentication enabled.

Patches

Update to at least v3.0.0-rc.3

Workarounds

There is no way to work around this issue without patching if your system requires token authentication.

References

The issue lies in how the JWK verification is performed. When a JWT contains a JWK header without a certificate chain, the code only checks if the KeyID (kid) matches one of the trusted keys, but doesn’t verify that the actual key material matches.

Here’s the problematic flow:

  1. An attacker generates their own key pair
  2. They create a JWT and include their public key in the JWK header
  3. They set the kid in the JWK to match one of the trusted keys’ IDs (which they could potentially discover)
  4. They sign the JWT with their private key
  5. The registry only checks if the kid exists in the trusted keys map but then uses the attacker’s public key from the JWK to verify the signature
ghsa
#git#auth
  1. GitHub Advisory Database
  2. GitHub Reviewed
  3. CVE-2025-24976

Distribution’s token authentication allows to inject an untrusted signing key in a JWT

High severity GitHub Reviewed Published Feb 11, 2025 in distribution/distribution • Updated Feb 11, 2025

Package

gomod github.com/distribution/distribution/v3 (Go)

Affected versions

> 3.0.0-beta.1, < 3.0.0-rc.3

Patched versions

3.0.0-rc.3

Impact

Systems running registry version > 3.0.0-beta.1 with token authentication enabled.

Patches

Update to at least v3.0.0-rc.3

Workarounds

There is no way to work around this issue without patching if your system requires token authentication.

References

The issue lies in how the JWK verification is performed. When a JWT contains a JWK header without a certificate chain, the code only checks if the KeyID (kid) matches one of the trusted keys, but doesn’t verify that the actual key material matches.

Here’s the problematic flow:

  1. An attacker generates their own key pair
  2. They create a JWT and include their public key in the JWK header
  3. They set the kid in the JWK to match one of the trusted keys’ IDs (which they could potentially discover)
  4. They sign the JWT with their private key
  5. The registry only checks if the kid exists in the trusted keys map but then uses the attacker’s public key from the JWK to verify the signature

References

  • GHSA-phw4-mc57-4hwc
  • distribution/distribution@5ea9aa0

Published to the GitHub Advisory Database

Feb 11, 2025

Last updated

Feb 11, 2025

ghsa: Latest News

GHSA-r399-636x-v7f6: LangChain serialization injection vulnerability enables secret extraction