How severe is GHSA-qhh4-458h-xwh2?

No CVSS score has been assigned to GHSA-qhh4-458h-xwh2 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-qhh4-458h-xwh2?

GHSA-qhh4-458h-xwh2 affects the following packages: @cyclonedx/cdxgen (npm). Ecosystems affected: npm.

How do I fix GHSA-qhh4-458h-xwh2?

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.

How do I detect GHSA-qhh4-458h-xwh2 in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @cyclonedx/cdxgen. 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.

How do I mitigate GHSA-qhh4-458h-xwh2 if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-qhh4-458h-xwh2?

O3 pinpoints whether GHSA-qhh4-458h-xwh2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-qhh4-458h-xwh2 actively exploited in the wild?

No public exploit code has been indexed for GHSA-qhh4-458h-xwh2 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-qhh4-458h-xwh2 published, and has it been updated?

GHSA-qhh4-458h-xwh2 was published on May 8, 2026 and was last updated on May 8, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 npm

GHSA-qhh4-458h-xwh2

@cyclonedx/cdxgen: Docker registry auth substring match forwards credentials to a different registry

Published

May 8, 2026

Updated

May 8, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.

@cyclonedx/cdxgennpm

161Kdownloads / week

Description

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

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`@cyclonedx/cdxgen`	≥ 9.9.5&&< 12.3.3	12.3.3

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @cyclonedx/cdxgen. 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 @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 pinpoints whether GHSA-qhh4-458h-xwh2 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-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

# 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` h

O3 Security · Impact-Aware SCA

Is GHSA-qhh4-458h-xwh2 in your dependencies?

O3 detects GHSA-qhh4-458h-xwh2 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works