Summary
@cyclonedx/cdxgen: Docker registry auth substring match forwards credentials to a different registry
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.
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"
}
}
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
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.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-QHH4-458H-XWH2? GHSA-QHH4-458H-XWH2 is a medium-severity security vulnerability in @cyclonedx/cdxgen (npm), affecting versions >= 9.9.5, < 12.3.3. It is fixed in 12.3.3.
- Which versions of @cyclonedx/cdxgen are affected by GHSA-QHH4-458H-XWH2? @cyclonedx/cdxgen (npm) versions >= 9.9.5, < 12.3.3 is affected.
- Is there a fix for GHSA-QHH4-458H-XWH2? Yes. GHSA-QHH4-458H-XWH2 is fixed in 12.3.3. Upgrade to this version or later.
- Is GHSA-QHH4-458H-XWH2 exploitable, and should I be worried? Whether GHSA-QHH4-458H-XWH2 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-QHH4-458H-XWH2 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-QHH4-458H-XWH2? Upgrade
@cyclonedx/cdxgento 12.3.3 or later.