CVE-2023-25762

What it actually does

Jenkins Pipeline: Build Step Plugin 2.18 and earlier fails to properly escape Jenkins job names before inserting them into a JavaScript expression used by the Pipeline Snippet Generator. An authenticated attacker with permission to create or rename jobs can store a malicious job name containing script content. When another user views the affected Pipeline Snippet Generator interface, the attacker-controlled JavaScript executes in that user’s browser in the Jenkins origin. This can allow theft of browser-accessible data, abuse of the victim’s Jenkins session, unauthorized job or configuration changes within the victim’s permissions, and potential chaining with other Jenkins weaknesses or excessive permissions.

Why it matters to the business

A low-privileged Jenkins user who can control job names may be able to compromise higher-privileged users through the web UI. In practical terms, this can lead to unauthorized pipeline changes, exposure of build metadata or secrets visible to the victim, disruption of CI/CD workflows, and a loss of trust in build integrity. Although it is not listed in CISA KEV and has no confirmed ransomware association, the EPSS score is high, indicating elevated likelihood of exploitation activity relative to many other vulnerabilities; Jenkins environments with broad job-creation permissions should treat remediation as urgent.

How an attack unfolds

An attacker first obtains Jenkins access with permissions sufficient to create or rename a job. They create a job whose name contains a JavaScript payload crafted to break out of the vulnerable JavaScript context used by the Pipeline Snippet Generator. The malicious name is stored by Jenkins. The attacker then waits for, or socially engineers, a developer or administrator to open the Pipeline Snippet Generator page where job names are rendered by the Pipeline: Build Step Plugin. When the page loads, the payload executes in the victim’s browser under the Jenkins web origin. From there, the script can attempt to read page content, capture anti-CSRF crumbs or other browser-accessible values, issue authenticated requests as the victim, alter pipeline configuration, trigger builds, or exfiltrate information reachable by the victim’s session. The impact depends heavily on the victim’s Jenkins permissions and the presence of compensating controls such as strict authorization and session protections.

How to fix it

Upgrade Jenkins Pipeline: Build Step Plugin to a fixed version, specifically 2.18.1 or later where available from the Jenkins update center. If centralized plugin management is used, ensure all Jenkins controllers using the plugin receive the updated plugin and are restarted or safely reloaded as required. As a mitigation until upgrade is complete, restrict job create, rename, and configure permissions to trusted users only; review and remove suspicious job names; limit access to the Pipeline Snippet Generator to authenticated trusted users; and enforce least-privilege role assignments so compromised sessions cannot broadly alter CI/CD workflows. Also keep Jenkins core and related Pipeline plugins current, because XSS in Jenkins is often more damaging when combined with overly broad administrative privileges or older plugin vulnerabilities.

How to confirm the fix worked

Confirm the installed Pipeline: Build Step Plugin version is greater than 2.18, preferably 2.18.1 or later. Validate through Jenkins plugin management, the plugin manager API, or the plugin directory metadata on the controller. Review all Jenkins controllers, not only the primary instance, for the vulnerable plugin. As a functional check in a non-production test environment, create a benign job name containing characters that would previously break JavaScript context, such as angle brackets and quotes, and confirm the Pipeline Snippet Generator displays it safely as text rather than executing it. Review authorization settings to ensure only trusted users can create, rename, or configure jobs. Confirm there are no existing job names containing script tags, JavaScript URLs, HTML event handlers, encoded angle brackets, or other browser-executable payload patterns.

Typical attack path

1. Gain authenticated access to Jenkins with permission to create, configure, or rename jobs.
2. Create or rename a job using a name that contains an XSS payload such as encoded script, event-handler, or JavaScript-breaking syntax.
3. Allow the malicious job name to be stored in Jenkins.
4. Induce or wait for a more privileged user to open the Pipeline Snippet Generator interface.
5. The vulnerable plugin inserts the unescaped job name into JavaScript, causing the payload to execute in the victim’s browser.
6. Use the victim’s Jenkins session to read accessible data, perform unauthorized actions, modify CI/CD configuration, trigger builds, or exfiltrate sensitive information.
7. Optionally chain the browser-session compromise with excessive Jenkins permissions, exposed credentials, or unsafe pipeline behavior to expand impact.

How to detect it

To determine whether this was already exploited, review Jenkins audit logs, controller logs, web access logs, and reverse-proxy logs for suspicious job creation, copy, configure, or rename activity involving job names with HTML or JavaScript-like content. Search Jenkins job configuration directories and exported job metadata for encoded or literal XSS payloads in job names. Correlate suspicious job-name changes with subsequent visits to Pipeline Snippet Generator pages, especially by administrators or users with broad Jenkins permissions. After such visits, look for unexpected authenticated requests from the victim’s session, including job reconfiguration, credential-management access, build triggers, pipeline script changes, token creation, user configuration changes, or administrative endpoint access. If available, inspect audit trails for actions performed by privileged users that are inconsistent with normal behavior and occurred immediately after they accessed pipeline syntax or snippet generator URLs. Browser forensics may show script execution or outbound connections to attacker-controlled domains, but server-side Jenkins and proxy logs are usually the most reliable evidence sources.

• <script
• </script>
• %3Cscript
• %3C%2Fscript%3E
• javascript:
• onerror=
• onload=
• onclick=
• document.cookie
• Jenkins-Crumb
• /pipeline-syntax/
• /descriptorByName/org.jenkinsci.plugins.workflow.support.steps.build.BuildTriggerStep
• /createItem
• /doRename
• /configSubmit
• jobs/*/config.xml

What your security team should do

• Prioritize upgrading Pipeline: Build Step Plugin to 2.18.1 or later across all Jenkins controllers because the EPSS score indicates heightened exploitation likelihood despite no KEV listing.
• Inventory Jenkins instances and identify where Pipeline: Build Step Plugin 2.18 or earlier is installed.
• Search existing Jenkins job names and configuration files for XSS payload patterns before and after patching.
• Temporarily restrict job creation, rename, and configure permissions to trusted users until the upgrade and review are complete.
• Review Jenkins audit, access, and reverse-proxy logs for suspicious job creation or rename events followed by privileged users accessing Pipeline Snippet Generator pages.
• Investigate any suspicious browser-originated Jenkins actions performed shortly after a user viewed the Pipeline Snippet Generator, especially configuration changes, credential access attempts, build triggers, or script console access attempts.
• Reinforce Jenkins least privilege by separating ordinary developer permissions from administrative, credential-management, and controller-level permissions.
• Ensure Jenkins core and all Pipeline-related plugins are updated, since XSS impact is amplified in outdated or over-permissive Jenkins deployments.