Skip to content

@cyclonedx/cdxgen: Maven project scanning may allow shell command injection through repository-controlled module paths

Moderate severity GitHub Reviewed Published May 22, 2026 in cdxgen/cdxgen • Updated Jun 26, 2026

Package

npm @cyclonedx/cdxgen (npm)

Affected versions

< 12.4.3

Patched versions

12.4.3

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

References

@prabhu prabhu published to cdxgen/cdxgen May 22, 2026
Published to the GitHub Advisory Database Jun 26, 2026
Reviewed Jun 26, 2026
Last updated Jun 26, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality Low
Integrity Low
Availability None
Subsequent System Impact Metrics
Confidentiality Low
Integrity Low
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N

EPSS score

Weaknesses

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Learn more on MITRE.

Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')

The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string. Learn more on MITRE.

CVE ID

No known CVE

GHSA ID

GHSA-5vwr-qchf-q4pf

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.