GHSA-3p65-76g6-3w7r is a high-severity (CVSS 7.5) Server-Side Request Forgery (SSRF) vulnerability in github.com/distribution/distribution/v3. O3 Security confirms whether GHSA-3p65-76g6-3w7r is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Distribution affected by pull-through cache credential exfiltration via www-authenticate bearer realm
Real-World Exposure
github.com/distribution/distribution/v3🐹github.com/distribution/distributionReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
hi guys,
commit: 40594bd98e6d6ed993b5c6021c93fdf96d2e5851 (as-of 2026-01-31) contact: GitHub Security Advisory (https://github.com/distribution/distribution/security/advisories/new)
summary
in pull-through cache mode, distribution discovers token auth endpoints by parsing WWW-Authenticate challenges returned by the configured upstream registry. the realm URL from a bearer challenge is used without validating that it matches the upstream registry host. as a result, an attacker-controlled upstream (or an attacker with MitM position to the upstream) can cause distribution to send the configured upstream credentials via basic auth to an attacker-controlled realm URL.
this is the same vulnerability class as CVE-2020-15157 (containerd), but in distribution’s pull-through cache proxy auth flow.
severity
HIGH
note: the baseline impact is credential disclosure of the configured upstream credentials. if a deployment uses broader credentials for upstream auth (for example cloud iam credentials), the downstream impact can be higher; i am not claiming this as default for all deployments.
impact
credential exfiltration of the upstream authentication material configured for the pull-through cache.
attacker starting positions that make this realistic:
- supply chain / configuration: an operator configures a proxy cache to use an upstream that becomes attacker-controlled (compromised registry, stale domain, or a malicious mirror)
- network: MitM on the upstream connection in environments where the upstream is reachable over insecure transport or a compromised network path
affected components
registry/proxy/proxyauth.go:66-81(getAuthURLs): extracts bearerrealmfrom upstreamWWW-Authenticatewithout validating destinationinternal/client/auth/session.go:485-510(fetchToken): uses the realm URL directly for token fetchinternal/client/auth/session.go:429-434(fetchTokenWithBasicAuth): sends credentials via basic auth to the realm URL
reproduction
attachment: poc.zip (local harness) with canonical and control runs.
the harness is local and does not contact a real registry: it uses two local HTTP servers (upstream + attacker token service) to demonstrate whether basic auth is sent to an attacker-chosen realm.
unzip -q -o poc.zip -d poc
cd poc
make canonical
make control
expected output (excerpt):
[CALLSITE_HIT]: getAuthURLs::configureAuth
[PROOF_MARKER]: basic_auth_sent=true realm_host=127.0.0.1 account_param=user authorization_prefix=Basic
control output (excerpt):
[CALLSITE_HIT]: getAuthURLs::configureAuth
[NC_MARKER]: realm_validation=PASS basic_auth_sent=false
suggested remediation
validate that the token realm destination is within the intended trust boundary before associating credentials with it or sending any authentication to it. one conservative option is strict same-host binding: only accept a realm whose host matches the configured upstream host.
fix accepted when
- distribution does not send configured upstream credentials to an attacker-chosen realm URL
- a regression test covers the canonical and blocked cases
addendum.md poc.zip PR_DESCRIPTION.md RUNNABLE_POC.md
best, oleh
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/distribution/distribution/v3 | all versions | 3.1.0 |
| 🐹Go | github.com/distribution/distribution | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/distribution/distribution/v3. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/distribution/distribution/v3 to 3.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3p65-76g6-3w7r is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-3p65-76g6-3w7r is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-3p65-76g6-3w7r. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3p65-76g6-3w7r in your dependencies?
O3 detects GHSA-3p65-76g6-3w7r across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.