GHSA-qhh4-458h-xwh2 — @cyclonedx/cdxgen
GHSA-qhh4-458h-xwh2 is a security vulnerability in @cyclonedx/cdxgen. A fix is available for @cyclonedx/cdxgen — see the affected versions and patch details below.
@cyclonedx/cdxgen: Docker registry auth substring match forwards credentials to a different registry
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@cyclonedx/cdxgennpmDescription
Docker registry auth substring match forwards credentials to a different registry
Repository
cdxgen/cdxgen
Affected product/package
- Ecosystem: npm
- Package:
@cyclonedx/cdxgen - Reviewed tree version:
12.3.3 - Reviewed commit:
b1e179869fd7c6032c3d483c3f7bd4d7154ec22b - Affected file:
lib/managers/docker.js - Affected from: v9.9.5
The Single Executable Applications (SEA) binaries and container images are also affected.
Weakness
CWE-522 / CWE-346.
Summary
When cdxgen scans or pulls container images through the Docker daemon API, it builds an X-Registry-Auth header from Docker credentials in DOCKER_CONFIG/config.json. The credential selection logic matches configured registry keys with substring checks:
if (forRegistry && !serverAddress.includes(forRegistry)) {
continue;
}
This is not an origin-safe registry comparison. For example, credentials configured for private-registry.example.com are selected for a requested image under registry.example.com, because:
"private-registry.example.com".includes("registry.example.com") === true
The selected credentials are then serialized into X-Registry-Auth for the Docker API pull request targeting the requested registry.
Reproduction
Use the attached/local proof:
node submissions/github-gsa/cdxgen-docker-registry-auth-substring-forwarding/evidence/cdxgen_docker_registry_auth_substring_probe.mjs
The proof is fully local. It creates a temporary Docker config containing credentials for private-registry.example.com, starts a localhost mock Docker API endpoint, sets DOCKER_HOST to that endpoint, then calls cdxgen's exported Docker request path for a pull from registry.example.com.
Observed vulnerable output:
{
"decision": "GO",
"dockerConfigAuthHost": "private-registry.example.com",
"requestedRegistry": "registry.example.com",
"substringMatch": true,
"dockerApiUrl": "/images/create?fromImage=registry.example.com/team/app:latest",
"headerPresent": true,
"decodedHeader": {
"username": "trusted-user",
"password": "trusted-pass",
"serveraddress": "private-registry.example.com"
}
}
Impact
If an operator has Docker credentials for a private registry and uses cdxgen to scan an image from a different registry whose hostname is a substring of that private registry hostname, cdxgen can attach the private registry credentials to the Docker pull request for the different registry.
In a realistic attack, an attacker who controls or can observe the requested registry can induce a victim to scan an image from that registry. The Docker daemon API receives an X-Registry-Auth payload containing credentials for the victim's private registry but associated with the attacker-requested pull. This is a credential forwarding/misbinding issue in cdxgen's container image handling.
References
Functions normalizeRegistryHost and registriesMatch added to normalize and perform strict host matching.
Fix PR: https://github.com/cdxgen/cdxgen/pull/3964
Researcher: Francesco SabiuResearcher: Francesco Sabiu
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @cyclonedx/cdxgen | ≥ 9.9.5&&< 12.3.3 | 12.3.3npm install @cyclonedx/cdxgen@12.3.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @cyclonedx/cdxgen, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @cyclonedx/cdxgen to 12.3.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qhh4-458h-xwh2 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-qhh4-458h-xwh2 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-qhh4-458h-xwh2. 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-qhh4-458h-xwh2 in your dependencies?
O3 Security finds GHSA-qhh4-458h-xwh2 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.