blackduck-c-cpp EUVD-2026-64894

The attacker must have the ability to execute arbitrary code within the scanned project's build environment - achieved, for example, through a malicious build script (Makefile target, CMake custom command), a compromised or malicious C/C++ dependency that runs code at build time, or a supply chain injection into the project's source tree. The vulnerability is exclusively triggered when the Black Duck API token is supplied via the BLACKDUCK_API_TOKEN or BD_HUB_TOKEN environment variable; configurations that inject the token through a file, a dedicated credential store, or a mechanism that does not expose it in the process environment are not vulnerable to this specific flaw. The CVSS 4.0 AT:P metric confirms that these specific attack requirements must be present. Exploitation is limited by: (1) requirement for code execution inside the build environment, (2) the non-default nature of allowing untrusted or third-party code to run during build scans, and (3) the fact that well-isolated CI environments with no outbound network access would prevent exfiltration even if the token is read.

The CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:L) correctly identifies local access with low complexity, but AT:P (attack requirements present) is the critical gating condition: exploitation requires code execution inside the build environment, which is a non-trivial prerequisite in hardened CI/CD pipelines. The subsequent-system impact metrics (SC:H/SI:H) are realistic - a stolen API token grants broad access to the Black Duck Hub, potentially enabling enumeration of all scanned repositories and manipulation of scan results. No EPSS score was provided in the input data, and no CISA KEV listing is indicated, meaning widespread automated exploitation has not been confirmed. The absence of a KEV listing should not be read as low urgency: any CI pipeline currently using affected versions with token-via-environment-variable configuration has already exposed its token to any build-time code, and the vendor's own advisory states that the damage is not undone by upgrading. The true risk gate is whether the build environment is trusted and isolated - organizations running blackduck-c-cpp against untrusted or third-party code have the highest exposure.

A threat actor embeds a malicious rule in a project's Makefile or a compromised C/C++ dependency that, when executed during blackduck-c-cpp's build capture phase, reads /proc/self/environ (or calls getenv()) to extract the BLACKDUCK_API_TOKEN value and exfiltrates it to an attacker-controlled endpoint. With the stolen token, the attacker authenticates to the Black Duck Hub API, enumerates all scanned projects and their vulnerability reports, and potentially modifies scan results to suppress findings - undermining the integrity of the organization's SCA program. No public exploit code has been identified at time of analysis, but the technique requires no specialized tooling.