openssl-encrypt EUVD-2026-67065

Exploitation requires both of the following: (1) the --debug flag must be explicitly passed when invoking 'keyserver set-token <token>' - the token is not exposed in normal (non-debug) operation, and the --unsafe-show-secrets guard does not govern this path; (2) an attacker must have read access to the stderr output, which could be a local terminal session, shared shell history, a CI/CD build log (e.g., GitHub Actions, Jenkins), or a centralized log aggregation system. Deployments that never use 'keyserver set-token' or never enable --debug are not affected. Limiting factors: the vulnerability does not allow remote unauthenticated access to the token without prior log access; it produces no network-reachable exposure on its own.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, score 8.7) represents a theoretical ceiling that requires scrutiny. Practically, exploitation depends on two preconditions that substantially reduce opportunistic risk: a legitimate operator must invoke 'keyserver set-token' with --debug active, and an attacker must have read access to the resulting stderr output (CI/CD pipeline logs, centralized log aggregation, shared terminal sessions, or shell history files). The PR:N and UI:N assignments in the provided vector appear to reflect worst-case assumptions about log accessibility rather than direct network exploitability. In environments where debug output flows into shared CI platforms (GitHub Actions logs, Jenkins console, etc.), the effective attack surface becomes broader and the risk materially higher. No EPSS data was provided; no CISA KEV listing and no POC availability are confirmed. Real-world priority should be elevated for teams running this package in CI/CD pipelines where build logs are accessible to multiple users or external contributors.

A developer or automated CI/CD job invokes 'keyserver set-token <BEARER_TOKEN> --debug' during a pipeline run; the token appears in cleartext in the build log output visible to all contributors with repository access. An attacker - an insider, a malicious contributor, or someone who gains read access to the CI platform - retrieves the token from the logs and uses it to authenticate to the keyserver, accessing or exfiltrating protected resources without further exploitation steps.