Jenkins HashiCorp Vault Plugin CVE-2025-67642

Requires the Jenkins HashiCorp Vault Plugin (version 371.v884a_4dd60fb_6 or earlier) to be installed and configured to resolve Vault credentials, and the attacker must hold an authenticated Jenkins account with Item/Configure permission. The flaw is that the plugin does not set the appropriate context for the Vault credentials lookup, so the limiting factors are: valid authentication, the Item/Configure grant (not available to anonymous or read-only users), and the plugin being deployed with Vault-backed credentials. There is no unauthenticated path and no victim user interaction needed beyond the attacker's own authenticated actions.

This is a genuinely moderate-to-low priority issue, not a top-tier emergency, and the signals are consistent. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3) describes a network-reachable but privilege-requiring flaw: an attacker must already hold Jenkins Item/Configure permission, so this is an authenticated insider/privilege-boundary problem rather than an unauthenticated remote compromise. Impact is limited to confidentiality (C:L) - disclosure of Vault credentials - with no integrity or availability effect. EPSS is low at 0.23% (13th percentile), aligning with the absence of CISA KEV listing and the absence of any referenced public exploit code, so there is no indication of active or imminent widespread exploitation. The classification (CWE-282, Improper Ownership Management) matches the described missing-context flaw. No signals conflict here: a legitimate, trusted vendor (Jenkins SECURITY team) reported it, and all exploitation/severity indicators point the same direction. The main caveat is that although C:L understates the real-world sensitivity of leaked Vault secrets (which could unlock downstream systems), the raw CVSS per spec is correct because the vulnerability itself only exposes the credential within Jenkins.

A Jenkins user who has been granted Item/Configure permission on a job (for example a developer with limited project-level access) crafts or edits a job configuration so that the plugin performs a Vault credentials lookup in a context that does not properly scope which credentials are visible, causing it to resolve and expose Vault credentials belonging to other folders/jobs the user should not reach. The attacker then captures those credentials (e.g., via a build step that echoes or exfiltrates them). No public exploit code is identified at time of analysis, and exploitation requires an authenticated low-privileged account.