Jenkins CVE-2025-67637

Exploitation requires that the attacker already hold Jenkins Item/Extended Read permission on the affected job, OR have read access to the Jenkins controller's filesystem where job config.xml files are stored. The vulnerable data is the build authorization token, which is present whenever a job is configured to use such a token; jobs without configured build tokens expose nothing. Limiting factors: this is authenticated (PR:L) - an anonymous external attacker cannot reach the data without first obtaining a low-privileged account or controller access - and the impact is confined to disclosure of the token (C:L), with no integrity or availability effect. This is a default storage behavior of affected Jenkins versions, not dependent on a special non-default configuration.

This is a low-to-moderate priority information-disclosure issue, not an urgent threat. The CVSS 3.1 base score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) reflects a network-accessible but authenticated flaw with only limited confidentiality impact and no integrity or availability impact - consistent with CWE-312 (cleartext storage of sensitive data). All signals align toward low real-world risk: EPSS is 0.18% (7th percentile), there is no CISA KEV listing, and no public exploit was identified. Exploitation requires an attacker to already hold Item/Extended Read permission or direct access to the controller filesystem, so the primary threat is a semi-trusted insider or a secondary attacker who has already compromised a low-privileged account, rather than an external unauthenticated adversary. The signals are internally consistent and non-conflicting; there is no CVSS-vs-description mismatch here. The main value of the exposed data is the build authorization tokens themselves, which could enable further abuse of triggering/CI functionality, so prioritization should follow Jenkins' general patch cadence rather than emergency response.

A user granted Item/Extended Read on a Jenkins job (or any account/process able to read the controller's job config.xml files) opens the job configuration and reads the build authorization token stored in cleartext. No public proof-of-concept is required - the token is simply visible in the stored XML - and because exploitation is authenticated and low-complexity (AV:N/AC:L/PR:L), it is trivial for anyone already holding the needed read permission.