CVE-2025-67639

What it actually does

This is a low-severity cross-site request forgery flaw in Jenkins login handling. In Jenkins 2.540 and earlier and Jenkins LTS 2.528.2 and earlier, an attacker can cause a victim’s browser to submit a forged login request that authenticates the victim’s Jenkins session as an attacker-controlled account. This does not directly give the attacker the victim’s Jenkins credentials or permissions, but it can create misleading session state, cause subsequent victim actions to occur under the attacker’s account, interfere with audit attribution, and potentially expose actions or data the victim enters while unknowingly operating in the attacker-controlled session.

Why it matters to the business

The main risk is operational confusion and audit integrity loss in Jenkins environments. A user may believe they are using Jenkins normally while actually logged in as an attacker-controlled account, causing builds, configuration changes, approvals, or other activity to be attributed to the wrong identity if that account has sufficient permissions. The CVSS score is low, EPSS is very low, it is not in CISA KEV, and there is no known mature public exploitation indicated, so this should be prioritized behind actively exploited Jenkins issues but still remediated during the normal Jenkins patch cycle because Jenkins often has access to sensitive build pipelines, release automation, and credentials.

How an attack unfolds

An attacker first creates or controls a Jenkins account, or identifies an account they can authenticate to. They then craft a web page, email link, embedded form, or other lure that causes the victim’s browser to send a login request to the target Jenkins instance using the attacker’s credentials or authentication flow. If the victim can reach the Jenkins instance and visits the attacker-controlled content, the browser submits the forged request and Jenkins accepts it, binding the victim’s session to the attacker-controlled account. The victim may then continue interacting with Jenkins without realizing the account context has changed. Any later actions are constrained by the permissions of the attacker-controlled account, but those actions may be observable to the attacker, misattributed in logs, or used to manipulate workflow decisions if the attacker-controlled account has access to jobs, builds, approvals, or configuration areas.

How to fix it

Upgrade Jenkins to a fixed release newer than Jenkins 2.540 or Jenkins LTS 2.528.2, or to a build that includes the upstream fix commit 40e29179c3edf88b685d7043ab7c37cc8591138f. Prefer current supported Jenkins weekly or LTS releases rather than cherry-picking if possible. If immediate upgrade is not possible, reduce exposure by restricting Jenkins access to trusted networks or VPN, requiring re-authentication for sensitive administrative actions where supported, reviewing permissions of low-privilege or self-service accounts, disabling unused accounts, and educating users to verify their logged-in identity before approving, configuring, or triggering sensitive jobs. These mitigations reduce likelihood and blast radius but do not fully correct the vulnerable login behavior.

How to confirm the fix worked

Confirm the deployed Jenkins version is newer than the affected ranges or includes commit 40e29179c3edf88b685d7043ab7c37cc8591138f. Administrators can validate from the Jenkins UI under Manage Jenkins, from package metadata, container image tags, or by checking the WAR/build provenance. After upgrade, test that a cross-origin auto-submitted login request cannot silently switch a user into another account without the expected protections. Also review reverse proxy and Jenkins access logs to ensure the instance is not broadly reachable from untrusted networks, and verify that security realm, account creation, and authorization settings follow least privilege.

Typical attack path

1. Attacker obtains or creates a Jenkins account they control.
2. Attacker crafts a malicious web page or form that submits a Jenkins login request to the vulnerable instance.
3. Attacker lures a Jenkins user into visiting the page while the user’s browser can reach the Jenkins server.
4. The victim’s browser sends the forged login request to Jenkins.
5. Jenkins authenticates the victim’s session as the attacker-controlled account.
6. The victim performs Jenkins actions believing they are operating normally.
7. Attacker reviews activity, build output, account-visible data, or audit artifacts associated with the attacker-controlled account, depending on permissions.

How to detect it

There are no reliable universal file or network indicators that prove exploitation, because exploitation uses normal Jenkins login requests. Detection should focus on behavioral evidence in Jenkins access logs, reverse proxy logs, authentication logs, audit trail logs if enabled, and build/job history. Look for successful login POSTs to Jenkins login endpoints that include an external or suspicious Referer or Origin header, especially followed by normal user activity from the same IP address and browser user-agent under an unexpected account. Investigate cases where a user reports being unexpectedly logged in as another account, where build or configuration activity is attributed to a rarely used account, or where the same session/IP/user-agent performs actions under an account inconsistent with the expected operator. If plugins such as Audit Trail, Job Config History, or external SSO/proxy logs are available, correlate login time, source IP, user-agent, session cookie issuance, job builds, configuration saves, credential-related activity, and approval actions. Because no known threat actors or mature public exploitation are indicated, prioritize this as a targeted phishing/social-engineering hunt rather than broad commodity scanning.

• POST /j_acegi_security_check
• POST /j_spring_security_check
• GET /login?from=
• Referer: http://
• Referer: https://
• Origin: http://
• Origin: https://
• Set-Cookie: JSESSIONID=
• Started by user
• hudson.model.UserIdCause

What your security team should do

• Patch Jenkins during the next regular maintenance window, prioritizing internet-facing or broadly reachable Jenkins controllers first.
• Inventory Jenkins controllers and confirm none are running Jenkins 2.540 or earlier, or Jenkins LTS 2.528.2 or earlier.
• Upgrade to a supported Jenkins weekly or LTS release containing fix commit 40e29179c3edf88b685d7043ab7c37cc8591138f.
• Review Jenkins accounts for unnecessary, stale, self-registered, or low-trust users, especially accounts with job read/build/configure permissions.
• Hunt for unusual login events where a user session appears to switch to a rarely used or externally controlled account after a request with an external Referer.
• Review recent sensitive Jenkins actions, approvals, job changes, and build triggers for unexpected user attribution.
• Restrict Jenkins administrative and developer access paths to trusted networks, VPN, SSO, or zero-trust access controls where feasible.