CVE-2025-67638

What it actually does

Jenkins 2.540 and earlier and Jenkins LTS 2.528.2 and earlier expose build authorization tokens in cleartext on the job configuration form instead of masking them. Any user, browser extension, screen recording tool, proxy, or attacker with sufficient access to view the job configuration page may observe and capture the token. The flaw does not by itself grant administrative access or remote code execution, but captured build tokens can be used to trigger jobs remotely, potentially with parameters, depending on how the affected job is configured.

Why it matters to the business

The primary risk is unauthorized triggering of Jenkins jobs, which can disrupt CI/CD operations, consume build resources, or indirectly affect software delivery pipelines. If jobs deploy software, publish artifacts, run privileged automation, or accept dangerous parameters, stolen tokens may enable broader operational impact. The vulnerability has a moderate CVSS score, very low EPSS, no known KEV listing, no known ransomware association, and no reported exploit maturity in the supplied data, so urgency is lower than for actively exploited Jenkins flaws, but Jenkins often sits in sensitive build and deployment paths and should still be remediated promptly.

How an attack unfolds

An attacker first obtains access to a Jenkins account or viewing path that can open a job configuration page, or observes a legitimate administrator’s browser/session through shoulder surfing, screen sharing, compromised endpoint telemetry, browser extensions, proxy logs, or screenshots. On vulnerable Jenkins versions, the build authorization token is rendered visibly on the configuration form rather than being masked. The attacker records the token and then uses Jenkins remote build endpoints, such as job build or parameterized build URLs with the token, to trigger the job without needing to know the full Jenkins user password. Impact depends on the job: a simple build may only consume resources, while a deployment or parameterized automation job may move code, publish artifacts, alter infrastructure, or run attacker-influenced commands if the job is unsafe.

How to fix it

Upgrade Jenkins to a fixed version that includes the vendor patch for this issue. The supplied fixed reference is jenkinsci/jenkins commit 40e29179c3edf88b685d7043ab7c37cc8591138f; operationally, deploy the Jenkins weekly or LTS release that incorporates this commit and is newer than Jenkins 2.540 or Jenkins LTS 2.528.2. After upgrading, rotate build authorization tokens for jobs that had remote build triggers enabled, especially jobs whose configuration pages may have been viewed by non-administrators or exposed through recordings, support bundles, screenshots, proxy logs, or browser telemetry. Where feasible, disable legacy job build tokens and use stronger authentication patterns such as API tokens scoped to service accounts, CSRF protection, least-privilege permissions, and network restrictions around Jenkins. Review parameterized jobs to ensure parameters cannot be used for command injection, unsafe deployment selection, or credential exposure.

How to confirm the fix worked

Confirm the Jenkins controller version is no longer Jenkins 2.540 or earlier and no longer Jenkins LTS 2.528.2 or earlier, and verify the deployed build contains commit 40e29179c3edf88b685d7043ab7c37cc8591138f or the corresponding vendor release. Open a non-production job with a remote build trigger enabled and confirm the token is no longer displayed in cleartext on the configuration form. Validate that rotated tokens work only where intended and that old tokens can no longer trigger builds. Review access controls to ensure only authorized job administrators can view or modify job configuration. Check reverse proxy, Jenkins access, and audit logs for remote build requests using token parameters before and after remediation.

Typical attack path

1. Identify a Jenkins controller running Jenkins 2.540 or earlier, or Jenkins LTS 2.528.2 or earlier.
2. Obtain the ability to view a job configuration page, or observe someone who can view it through browser/session monitoring, screen sharing, endpoint compromise, or proxy capture.
3. Open the affected job’s configuration form and capture the visible build authorization token.
4. Use the captured token against Jenkins remote build endpoints for that job, such as build or buildWithParameters URLs.
5. Trigger unauthorized builds, optionally supplying parameters if the job supports them.
6. Leverage the job’s configured privileges and downstream automation to cause disruption, unauthorized deployment, artifact publication, or other pipeline-side effects.

How to detect it

There is no single definitive indicator for exploitation because viewing a job configuration page may be normal administrative behavior and the exposed token is not necessarily logged. Hunt by correlating Jenkins access logs, reverse proxy logs, web server logs, Jenkins Audit Trail or equivalent audit plugin events, identity provider sign-in logs, endpoint/browser telemetry, and job build history. Look for users or IP addresses accessing job configuration pages shortly before remote build requests that include token parameters, especially for jobs they do not normally administer. Review requests to /job/.../configure, /job/.../config.xml, /job/.../build?token=, and /job/.../buildWithParameters?token=. Investigate builds triggered remotely at unusual times, from unusual source IPs, by unexpected users, or with unusual parameters. Examine job console logs and build parameters for evidence of unauthorized deployments, artifact publication, command execution, or changes to environment selection. If logs include query strings, treat any captured token values as compromised and rotate them. Also review screenshots, screen recordings, support bundles, proxy captures, and browser telemetry that may have stored visible configuration pages.

• /configure
• /config.xml
• /build?token=
• /buildWithParameters?token=
• /job/
• GET /job/
• POST /job/
• token=
• <authToken>
• authToken
• buildWithParameters
• Build Authorization Token
• Trigger builds remotely

What your security team should do

• Inventory Jenkins controllers and prioritize any running Jenkins 2.540 or earlier or Jenkins LTS 2.528.2 or earlier for upgrade.
• Patch to a Jenkins release containing commit 40e29179c3edf88b685d7043ab7c37cc8591138f or a later vendor-fixed release.
• Rotate build authorization tokens for all jobs that allow remote triggering, prioritizing deployment, release, artifact-publishing, infrastructure, and privileged automation jobs.
• Search logs for unusual access to job configuration pages and subsequent remote build requests using token parameters.
• Restrict who can view and configure Jenkins jobs; job configuration visibility should be limited to trusted administrators or maintainers.
• Reduce reliance on legacy remote build tokens; prefer authenticated service accounts with scoped API tokens, least privilege, and network controls.
• Review parameterized jobs for unsafe parameters that could turn unauthorized triggering into code execution, deployment abuse, or data exposure.
• If suspicious use is found, preserve Jenkins access logs, reverse proxy logs, audit trail records, job build history, console logs, and affected job configuration files for investigation.