Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

@cyclonedx/cdxgen: Maven project scanning may allow shell command injection through repository-controlled module pathsGHSA-5vwr-qchf-q4pf

Fix: cdxgen/cdxgen#4059

GHSA-5vwr-qchf-q4pf is a remote code execution vulnerability in @cyclonedx/cdxgen. A fix is available for @cyclonedx/cdxgen — see the affected versions and patch details below.

Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 10, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

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.

3other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@cyclonedx/cdxgennpm
182Kdownloads / week

Description

Summary

A command injection vulnerability existed in the Maven scanning flow of cdxgen before version 12.4.3.

When cdxgen scanned an attacker-controlled Maven project, repository-controlled paths could be used in the Maven command construction. In affected versions, some Maven invocations were executed with shell: true. A directory name containing shell metacharacters could therefore be interpreted by the shell instead of being treated only as a filesystem path.

This could allow an attacker who controls a scanned repository to execute commands in the cdxgen process context.

The issue affected both the CLI and server mode. The issue is patched in 12.4.3.

Affected asset

  • Project: cdxgen
  • Tested version: 12.4.1
  • Mode tested: server mode
  • Endpoint: POST /sbom
  • Scanner path: Java / Maven project scanning

Patch

Version 12.4.3 includes hardening for this issue with PR #4059

The patch adds multiple mitigations:

  • Maven command invocations no longer use unconditional shell execution on POSIX platforms.
  • Bazel command invocation was similarly changed away from unconditional shell execution.
  • Windows compatibility is preserved using shell: isWin where needed.
  • safeSpawnSync now blocks shell: true invocations when the command or direct argument values contain shell metacharacters.
  • cdxgen does not validate or sanitise every nested directory. The threat model is updated to clarify mitigation scope.

Workarounds

The recommended remediation is to upgrade to 12.4.3 or later.

If immediate upgrade is not possible:

  • Do not run cdxgen server mode on untrusted networks.
  • Do not expose POST /sbom to unauthenticated or untrusted clients.
  • Avoid scanning untrusted Java/Maven repositories.
  • Run cdxgen inside a locked-down container or sandbox.
  • Remove sensitive environment variables from the cdxgen process environment.
  • Use least-privilege filesystem mounts.
  • Restrict outbound network access where possible.

Use cdxgen secure/dry-run modes where suitable to inspect planned operations before performing scans. Configure host and command allowlists where applicable, such as:

  • CDXGEN_SERVER_ALLOWED_HOSTS
  • CDXGEN_GIT_ALLOWED_HOSTS
  • CDXGEN_ALLOWED_COMMANDS
  • CDXGEN_SECURE_MODE=true

These mitigations reduce exposure but do not fully address the vulnerable command construction in affected versions.

Threat model clarification

The mitigation added in 12.4.3 applies to the cdxgen process boundary. Specifically, cdxgen now hardens command, option, and path values that cdxgen itself passes to external processes through safeSpawnSync.

This does not mean cdxgen sanitizes every nested path, module name, generated path, or project-controlled value that an external build tool later discovers and interprets inside its own process. Once cdxgen safely invokes Maven, Gradle, Bazel, SBT, or another build tool, that tool’s internal behavior remains a separate trust boundary.

In scope for this fix:

  • command and argument values passed directly by cdxgen to child processes;
  • cdxgen’s own use of shell: true;
  • Maven/Bazel command invocation paths controlled by cdxgen.

Out of scope for this specific mitigation:

  • arbitrary nested paths later discovered by Maven itself;
  • Maven plugin behavior;
  • Maven lifecycle hooks;
  • build-tool-specific interpretation of project files after cdxgen has launched the tool.

This residual risk is documented in the cdxgen threat model and is why untrusted project scans should still be run in sandboxed, least-privileged environments.

Detection

Possible indicators of exploitation or probing include:

  • Maven module directories containing shell metacharacters such as:
;
&
|
<
>
$
backticks
newlines
  • Logs showing settings.xml or pom.xml discovered in suspicious paths.
  • Unexpected files created outside the scanned repository during a Java/Maven scan.
  • Unexpected child process behavior during cdxgen server scans.
  • cdxgen server receiving POST /sbom requests for attacker-controlled Git URLs.

Example suspicious path pattern:

evil;cd${IFS}..;cd${IFS}..;printf${IFS}...>...;#

Credits

Reported-By: @aleff-github

Resources

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@cyclonedx/cdxgenall versions12.4.3npm install @cyclonedx/cdxgen@12.4.3

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. Fix

    Update @cyclonedx/cdxgen to 12.4.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5vwr-qchf-q4pf is resolved across your whole dependency graph.

  3. Workarounds

    Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.

Frequently Asked Questions

## Summary A command injection vulnerability existed in the Maven scanning flow of cdxgen before version 12.4.3. When cdxgen scanned an attacker-controlled Maven project, repository-controlled paths could be used in the Maven command construction. In affected versions, some Maven invocations were executed with `shell: true`. A directory name containing shell metacharacters could therefore be interpreted by the shell instead of being treated only as a filesystem path. This could allow an attacker who controls a scanned repository to execute commands in the cdxgen process context. The issue
O3 Security · Impact-Aware SCA

Is GHSA-5vwr-qchf-q4pf in your dependencies?

Find it across npm, including transitive dependencies.

@cyclonedx/cdxgen: Maven project scanning may allow…