CVE-2025-27624

What it actually does

Jenkins 2.499 and earlier and Jenkins LTS 2.492.1 and earlier allow the sidepanel widget collapsed/expanded-state toggle endpoint to be invoked without requiring an HTTP POST request. Because the endpoint can be reached with a state-changing GET request and does not enforce the expected CSRF protection flow, an attacker can cause an authenticated Jenkins user’s browser to submit the request cross-site. The endpoint also accepts arbitrary strings as the panel identifier, causing attacker-controlled values to be persisted in the victim user’s Jenkins profile. The flaw does not by itself provide remote code execution, credential disclosure, or administrative privilege escalation, but it allows unauthorized modification of per-user UI/profile state and persistence of untrusted profile data.

Why it matters to the business

An attacker can make logged-in Jenkins users unknowingly change parts of their Jenkins profile simply by visiting attacker-controlled content. In practical terms, this can disrupt the Jenkins user interface, pollute user profiles with attacker-supplied values, create forensic noise, and potentially support chained attacks if other weaknesses later render or process that stored data unsafely. The operational risk is lower than vulnerabilities that compromise builds or secrets directly: EPSS is low, there is no CISA KEV listing, no known ransomware use, and no public exploit maturity is reported. However, Jenkins often supports critical CI/CD workflows, so exposed or widely used Jenkins controllers should still be patched during normal security maintenance.

How an attack unfolds

An attacker first identifies that a target organization uses a vulnerable Jenkins version. The attacker then crafts a web page, email link, embedded image, iframe, or other browser-delivered lure that causes the victim’s browser to issue a GET request to Jenkins’ sidepanel toggle endpoint with a chosen panel identifier. If the victim is currently authenticated to Jenkins and can reach the Jenkins controller from their browser, the request is sent with the victim’s session cookies. Because vulnerable Jenkins versions do not require POST for this state-changing action, Jenkins accepts the request and toggles the sidepanel widget state. If the attacker supplies an arbitrary panel ID value, that value can be saved into the victim’s user profile. The attacker does not need to know the victim’s Jenkins password or receive the response body; the victim’s browser performs the action on the attacker’s behalf.

How to fix it

Upgrade Jenkins to a fixed release: Jenkins weekly 2.500 or later, or Jenkins LTS 2.492.2 or later. If building Jenkins directly from source, ensure the fix corresponding to commit 02d4db379ac965641bb1382515c834cf4966ec5a is included. As defense-in-depth, restrict Jenkins access to trusted networks or VPNs, require authentication, keep CSRF protection enabled, and avoid exposing Jenkins controllers directly to the public internet. If immediate upgrade is not possible, reduce risk by limiting browser reachability to Jenkins, using reverse-proxy access controls, and warning users not to browse untrusted content while authenticated to Jenkins; these mitigations do not fully correct the vulnerable endpoint behavior.

How to confirm the fix worked

Confirm the Jenkins version is Jenkins weekly 2.500 or later or Jenkins LTS 2.492.2 or later through the Jenkins UI, CLI, package manager, container image tag, or controller startup logs. For source builds, confirm the fixed commit 02d4db379ac965641bb1382515c834cf4966ec5a or an equivalent patch is present. In a non-production or controlled test with a low-privilege test account, attempt a GET request to the sidepanel toggle endpoint with a test paneId value; fixed versions should require POST and should not change persisted profile state via GET. Also verify that a legitimate POST workflow still works as expected and that reverse proxies or caches are not rewriting methods in a way that bypasses the intended behavior.

Typical attack path

1. Identify or assume a Jenkins controller running Jenkins 2.499 or earlier, or Jenkins LTS 2.492.1 or earlier.
2. Prepare a CSRF lure that triggers a GET request to the Jenkins sidepanel widget collapse/expand toggle endpoint with an attacker-selected paneId value.
3. Deliver the lure through a web page, message, ticket, documentation page, or other content likely to be opened by an authenticated Jenkins user.
4. Victim’s browser sends the request to Jenkins with the victim’s existing Jenkins session cookies.
5. Vulnerable Jenkins accepts the state-changing GET request without requiring a POST request and CSRF protection.
6. Jenkins toggles the sidepanel widget state and may persist the attacker-supplied panel identifier in the victim’s user profile.
7. Attacker may repeat the action to cause UI disruption, profile pollution, or attempt to support follow-on/chained abuse.

How to detect it

Look for evidence in Jenkins access logs, Winstone logs, servlet container logs, and reverse-proxy logs such as NGINX, Apache HTTPD, ingress controller, or load balancer logs. Focus on GET requests to the sidepanel widget toggle endpoint, especially requests containing paneId parameters, requests with external or unusual Referer headers, requests that occur shortly after users visit non-Jenkins sites, or requests containing encoded HTML, JavaScript, shell-like strings, long random values, or repeated automated patterns. Correlate these requests with Jenkins user profile file modification times under the Jenkins home users directory. Review affected user profile XML/configuration data for unexpected persisted panel identifiers. Because this flaw only modifies user UI/profile state, there may be no process execution, new build, plugin installation, or credential access artifact directly attributable to this vulnerability unless it is chained with another issue.

• GET /toggleCollapse
• GET /jenkins/toggleCollapse
• toggleCollapse?paneId=
• /toggleCollapse?paneId=
• paneId=%3Cscript
• paneId=<script
• paneId=%3Cimg
• paneId=<img
• paneId=javascript:
• Referer: http://
• Referer: https://
• $JENKINS_HOME/users/*/config.xml

What your security team should do

• Inventory Jenkins controllers and prioritize upgrades for any running Jenkins 2.499 or earlier, or Jenkins LTS 2.492.1 or earlier.
• Upgrade to Jenkins 2.500+ or LTS 2.492.2+ during the next maintenance window; prioritize internet-accessible, shared, or high-privilege CI/CD controllers.
• Review Jenkins and reverse-proxy access logs for suspicious GET requests to the sidepanel toggle endpoint, especially with unusual paneId values or external Referer headers.
• Inspect recently modified Jenkins user profiles for unexpected or attacker-like panel identifiers, especially values containing HTML, script fragments, URL-encoded payloads, long random strings, or command-looking text.
• Keep Jenkins CSRF protection enabled and restrict Jenkins access to trusted networks or identity-aware access controls.
• Educate Jenkins administrators and developers that being logged in to Jenkins while browsing untrusted sites can expose them to CSRF-style attacks, particularly on unpatched controllers.