CVE-2026-53441

What it actually does

This is a stored cross-site scripting vulnerability in Jenkins agent configuration handling. An authenticated attacker with Agent/Configure permission can submit a crafted generic offline-cause description through the POST config.xml API for an agent. Jenkins versions 2.483 through 2.567 and LTS 2.492.1 through 2.555.2 do not properly escape that user-controlled description before rendering it in the Jenkins web UI. When another user views the affected agent or offline-cause information, attacker-supplied script can execute in that user’s browser in the Jenkins web application security context. The flaw requires low-privileged authenticated access and user interaction, but because the script runs in the Jenkins origin, it may be able to read page content, issue same-origin requests as the victim, alter Jenkins objects within the victim’s permissions, or facilitate credential/session abuse depending on browser and Jenkins hardening controls.

Why it matters to the business

A user with limited Jenkins agent-management rights could turn an agent description into a persistent browser-based attack against administrators or other Jenkins users. Successful exploitation could lead to unauthorized job, agent, credential, or configuration changes if a more privileged user views the affected page. For organizations relying on Jenkins for software delivery, this can create risk to build integrity, deployment pipelines, and sensitive CI/CD metadata. The current EPSS score is low and there is no known KEV listing or known ransomware association, so broad active exploitation is not indicated; however, Jenkins is commonly internet-exposed and highly privileged in software supply chains, making timely remediation important.

How an attack unfolds

An attacker first obtains a Jenkins account that has Agent/Configure permission for at least one agent. The attacker sends a crafted POST request to the agent config.xml API and sets the generic offline-cause description to include malicious HTML or JavaScript. Jenkins stores the value without sufficient output escaping. Later, when an administrator or another Jenkins user views the affected agent/offline-cause page, the payload is rendered by the browser and executes under the Jenkins web origin. The script can then interact with Jenkins as the victim user, such as reading page content, submitting configuration changes, triggering builds, or attempting to pivot toward higher-impact CI/CD actions permitted to the victim. Exploitation is opportunistic and depends on a privileged user visiting the affected UI after the malicious configuration is stored.

How to fix it

Upgrade Jenkins to a version that contains the vendor fix. The affected ranges are Jenkins weekly 2.483 through 2.567 inclusive and Jenkins LTS 2.492.1 through 2.555.2 inclusive; deploy the first fixed weekly release newer than 2.567 or the first fixed LTS release newer than 2.555.2 as provided by the Jenkins security advisory. If immediate upgrade is not possible, restrict Agent/Configure permission to trusted administrators only, review and remove unnecessary delegated agent-management rights, limit access to Jenkins to trusted networks or VPN, and inspect agent config.xml files for suspicious offline-cause descriptions containing HTML, JavaScript, event handlers, or javascript: URLs. As a compensating control, use reverse proxy/WAF rules to alert on or block POST requests to Jenkins agent config.xml endpoints that include script tags or common XSS patterns, but do not rely on filtering as a substitute for upgrading.

How to confirm the fix worked

Confirm the running Jenkins core version is outside the affected ranges: weekly builds should be newer than 2.567, and LTS installations should be newer than 2.555.2 once the fixed LTS is available. Verify that users and groups with Agent/Configure permission are limited to those with a business need. Review agent configuration files under JENKINS_HOME/nodes/ and the Jenkins UI for offline-cause descriptions containing markup, script tags, event-handler attributes, encoded HTML, or javascript: links. If a safe test environment is available, attempt to save a benign encoded XSS probe such as an inert script-like string in an offline-cause description and confirm it is displayed as text rather than executed or interpreted as HTML. Also validate that reverse proxy and Jenkins access logs capture POST requests to /computer/*/config.xml for future monitoring.

Typical attack path

1. Gain authenticated access to Jenkins with Agent/Configure permission.
2. Identify an agent that the account is allowed to configure.
3. Submit a POST request to the agent config.xml endpoint containing a malicious offline-cause description.
4. Wait for Jenkins to store the crafted description in the agent configuration or offline-cause metadata.
5. Lure or wait for a higher-privileged Jenkins user to view the affected agent/offline-cause page.
6. Execute JavaScript in the victim’s browser within the Jenkins origin.
7. Use the victim’s permissions to read sensitive UI data, submit Jenkins actions, alter configuration, or stage additional attacks.

How to detect it

To determine whether this was already exploited, review Jenkins access logs, reverse proxy logs, audit-trail plugin logs, and configuration-history records for POST requests to agent configuration endpoints, especially /computer/<agent>/config.xml. Focus on requests by non-administrative users or unexpected service accounts with Agent/Configure permission. Inspect request bodies where available for offline-cause or description fields containing script tags, HTML entities, event-handler attributes such as onerror or onload, iframe/object/svg tags, or javascript: URLs. Review files under JENKINS_HOME/nodes/*/config.xml and historical copies from configuration-history backups for suspicious temporaryOfflineCause, offlineCause, or description entries. If payloads are discovered, identify users who viewed the affected agent pages afterward by correlating GET requests to /computer/<agent>/ and related pages, then review their subsequent Jenkins actions for suspicious configuration changes, credential interactions, build triggers, script-console use, plugin installation, or new user/API token activity. Browser-side XSS may not leave a definitive server-side artifact beyond the stored payload and follow-on same-origin requests, so absence of a clear execution log does not rule out exploitation.

• POST /computer/
• /config.xml
• POST /computer/*/config.xml
• <temporaryOfflineCause
• temporaryOfflineCause
• offlineCause
• hudson.slaves.OfflineCause$SimpleOfflineCause
• <description><script
• <description>&lt;script
• <script>
• &lt;script&gt;
• </script>
• onerror=
• onload=
• onclick=
• onmouseover=
• javascript:
• <iframe
• &lt;iframe
• <svg
• &lt;svg
• <img
• &lt;img
• document.cookie
• fetch(
• XMLHttpRequest
• JENKINS_HOME/nodes/
• nodes/*/config.xml

What your security team should do

• Upgrade Jenkins core to a fixed release as the top priority, especially for internet-accessible or high-trust CI/CD controllers.
• Inventory Jenkins controllers and identify any running weekly 2.483-2.567 or LTS 2.492.1-2.555.2.
• Temporarily restrict Agent/Configure permission to trusted administrators until all controllers are remediated.
• Search Jenkins access logs, audit logs, and configuration history for recent POST requests to agent config.xml endpoints containing XSS-like payloads.
• Inspect JENKINS_HOME/nodes/*/config.xml and any configuration-history plugin records for suspicious offline-cause description values.
• If suspicious payloads are found, treat impacted Jenkins sessions and any actions performed by users who viewed the affected agent pages as potentially compromised.
• Add SIEM detections for POST requests to /computer/*/config.xml containing script tags, event-handler attributes, encoded HTML, or javascript: URLs.
• Review Jenkins administrative activity after suspected exposure, including job changes, credential access, plugin changes, script-console use, agent changes, and build triggers.