CVE-2025-67637

What it actually does

The vulnerability allows for the storage of build authorization tokens in an unencrypted, plaintext format within job configuration files (config.xml) on the Jenkins controller. Any user or process with permission to read these files, either through Jenkins' 'Item/Extended Read' permission or direct filesystem access, can view these sensitive tokens. This constitutes an information disclosure flaw, specifically exposing credentials used to trigger builds.

Why it matters to the business

Exposure of build authorization tokens can allow unauthorized individuals to trigger software builds and deployments. This could lead to the injection of malicious code into the software supply chain, unauthorized deployment of applications, service disruptions, or excessive resource consumption. Compromise of the CI/CD pipeline represents a significant threat to operational integrity and the security of software delivered to customers.

How an attack unfolds

An attacker with pre-existing access, either as a low-privileged Jenkins user with 'Item/Extended Read' permission or with access to the controller's filesystem, can exploit this vulnerability. The attacker navigates to the Jenkins jobs directory and reads the 'config.xml' file for a specific job. Inside this XML file, they find the plaintext build authorization token. Using this stolen token, the attacker can then send a request to the Jenkins API to trigger the corresponding build remotely, bypassing standard authentication and authorization controls for that action.

How to fix it

To remediate this vulnerability, upgrade Jenkins to version 2.541 or newer, or for LTS users, to version 2.528.3 or newer. After upgrading, existing tokens will remain unencrypted. To protect them, you must either regenerate the tokens or simply re-save each job's configuration, which will cause Jenkins to store the tokens in the new encrypted format. As a mitigating control, strictly limit 'Item/Extended Read' permissions to essential, highly-trusted administrative accounts and enforce strong access controls on the Jenkins controller's filesystem.

How to confirm the fix worked

To validate if you are exposed, inspect the 'config.xml' files within the job directories on your Jenkins controller's filesystem. Search for the '<authToken>' or a similar element; if the value is a human-readable string, it is stored in plaintext and you are vulnerable. After upgrading and re-saving the job configurations, the value within this tag should be an encrypted hash, typically a long alphanumeric string enclosed in curly braces, confirming the fix has been applied.

Typical attack path

1. Attacker gains access to the Jenkins controller filesystem or obtains an account with 'Item/Extended Read' permissions.
2. Attacker locates and reads a target job's 'config.xml' file.
3. Attacker extracts the plaintext build authorization token from the XML file.
4. Attacker uses the stolen token to remotely trigger the associated Jenkins job via its API endpoint, potentially with malicious parameters.

How to detect it

To detect potential exploitation, review Jenkins audit logs and web server access logs for unusual access to job configuration endpoints (e.g., '/job/*/config.xml'). Look for requests originating from unexpected IP addresses or associated with low-privileged user accounts. Correlate build history logs with access logs to identify any builds that were triggered anomalously, such as outside of business hours or by a user who should not have permission, as this may indicate the use of a stolen token.

• GET /job/.*/config.xml

What your security team should do

• Immediately prioritize upgrading all vulnerable Jenkins instances to a patched version (2.541+ or LTS 2.528.3+).
• After the upgrade, create a plan to re-save all job configurations to ensure existing build tokens are encrypted.
• Audit all roles and users for the 'Item/Extended Read' permission and remove it from any non-essential accounts.
• Review and harden filesystem permissions on the Jenkins controller host to prevent unauthorized access to job configuration files.