Jenkins Patches 20 Plugin Flaws Leading to RCE, XSS and Credential Theft

The Jenkins Script Security Plugin fails to check method invocations made through the dynamic proxy that is created when a sandboxed script coerces a value to an interface, when the underlying value inherits a method whose name matches the interface method. An attacker who already has permission to define and run sandboxed scripts — most commonly users able to create or configure Pipelines on a shared Jenkins controller — can craft a script that abuses this coercion path to escape the Groovy sandbox. Successful exploitation yields arbitrary code execution inside the Jenkins controller JVM, which typically means full control of the controller, its credentials/secrets, and all connected build agents. Any Jenkins instance running Script Security Plugin 1415.v9a_f9b_3a_c253d or earlier is affected, and because the plugin is a core dependency of Pipeline, that includes most modern Jenkins deployments. No public proof-of-concept, listing in CISA KEV, or confirmed in-the-wild exploitation is known at this time.

Do: Update the Script Security Plugin to the first release published after this advisory (any version later than 1415.v9a_f9b_3a_c253d), which all controllers using Pipelines should receive promptly. In the meantime, restrict who can define and run sandboxed scripts — review users/groups with Item/Configure or Pipeline job-creation rights and Overall/RunScripts permission on shared controllers — and audit existing sandboxed jobs for scripts that coerce values to interfaces. Since exploitation requires script-running privileges, single-user or tightly restricted Jenkins instances face substantially lower practical risk than multi-tenant controllers.

The Jenkins Script Security Plugin (1415.v9a_f9b_3a_c253d and earlier) fails to intercept Groovy operations performed on a null receiver — method calls, property and attribute accesses, and array accesses — leaving a gap in its sandbox protection mechanism (CWE-693). An attacker who already has permission to define and run sandboxed scripts, such as Pipeline jobs, can craft a script in which a null-receiver operation invokes privileged code that the sandbox never checks. Successful exploitation yields arbitrary code execution within the Jenkins controller JVM, giving the attacker full access to the controller, its stored credentials, and all jobs (CVSS 8.8 with high confidentiality, integrity, and availability impact). Any Jenkins controller running an affected plugin version where non-administrative users can author Pipelines or other sandboxed scripts is affected. No public proof-of-concept is known, the issue is not in CISA KEV, and there are no reports of exploitation in the wild.

Do: Update the Script Security Plugin to a release newer than 1415.v9a_f9b_3a_c253d as soon as a fixed version is published. Until then, restrict the permissions that allow users to create or edit Pipelines and other sandboxed scripts (e.g., Job/Configure and script-approval grants) to trusted users only, and review the sandbox approval list for overly broad approvals. Controllers that let anonymous or untrusted users define Pipelines carry the highest risk and should be prioritized, since exploitation requires authenticated script-authoring privileges.

The Jenkins Script Security Plugin, which restricts what Groovy code can do when users run sandboxed scripts, mishandles type casts on collections: it checks the operations Groovy performs with the elements read from a collection that a script casts to another type, but actually applies the cast to the collection itself. An attacker who already has permission to define and run sandboxed scripts, including Pipelines (a low-privilege, authenticated position per the CVSS vector), can craft a script that exploits this mismatch to perform operations the sandbox never approved. The result is a complete sandbox bypass and execution of arbitrary code in the context of the Jenkins controller JVM, giving the attacker control over the Jenkins instance, its stored credentials, jobs, and build agents. Any Jenkins controller running Script Security Plugin 1415.v9a_f9b_3a_c253d or earlier that grants sandboxed-script permissions to users is affected. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known at this time.

Do: Update the Script Security Plugin via the Jenkins update center to the newest release published after 1415.v9a_f9b_3a_c253d (see the Jenkins security advisory for the fixed version). Until patched, restrict which users or roles can define and run sandboxed scripts and Pipelines, and review controller logs for suspicious sandboxed-script activity. Administrators should re-check that the plugin is updated on every controller, since it is commonly pulled in automatically as a Pipeline dependency.

The Jenkins Script Security Plugin, up to and including version 1415.v9a_f9b_3a_c253d, fails to reject the @GroovyASTTransformationClass annotation in sandboxed Groovy code, which is CWE-94 code injection by design of the sandbox filter. An attacker who already has permission to define and run sandboxed scripts — typically any user able to create or modify Pipeline jobs — can supply an arbitrary Groovy AST (Abstract Syntax Tree) transformation that the compiler executes at compile time, outside the sandbox's method-level interception. This bypasses the sandbox entirely and yields arbitrary code execution in the Jenkins controller JVM, giving the attacker control of the CI/CD server, its stored credentials, secrets, and connected build agents. The flaw is consistent with its CVSS 3.1 score of 8.8 (network vector, low complexity, low authenticated privileges required, no user interaction), and it affects most Pipeline-based Jenkins deployments that permit non-administrator users to write Pipelines. As of this analysis there is no public proof-of-concept, the issue is not in CISA's Known Exploited Vulnerabilities catalog, and no in-the-wild exploitation is known.

Do: Update the Script Security Plugin via the Jenkins update center to the first release after 1415.v9a_f9b_3a_c253d. In the interim, restrict which users have permission to define and run Pipelines or other sandboxed scripts, and audit existing users with those rights. Treat pending script approvals with caution, since AST transformations execute at compile time — during compilation and approval — before any patched sandboxing of script content applies.

The Jenkins Script Security Plugin, which enforces sandbox restrictions on user-written Groovy scripts, fails to reject @Builder annotations whose builderStrategy member names an arbitrary class, allowing a sandbox bypass. An attacker who already has permission to define and run sandboxed scripts — typically authenticated users able to create or edit Pipelines — can craft a script that references a suitable 'gadget' class on the classpath of the component evaluating the script, causing that code to run outside the sandbox. Successful exploitation yields arbitrary code execution on the Jenkins controller, beyond the limits the sandbox is meant to enforce. Any Jenkins instance running Script Security Plugin 1415.v9a_f9b_3a_c253d or earlier that lets non-administrator users write sandboxed Pipelines or scripts is affected. No public proof-of-concept is known, the issue is not in CISA KEV, and no CVSS score has been assigned; a patch is indicated among Jenkins' recent batch of plugin fixes.

Do: Update the Script Security Plugin to the latest release (any version newer than 1415.v9a_f9b_3a_c253d). Until patched, restrict which users can define or run sandboxed Pipelines/scripts and audit job-creation and script-approval permissions on the controller. Admins should also review existing Pipeline definitions and script approvals for unexpected @Builder annotation usage.

The Jenkins Script Security Plugin up to and including 1415.v9a_f9b_3a_c253d automatically approves pending classpath entries in an item's configuration whenever a user with Overall/Administer permission copies that item, or saves its configuration through the REST API or CLI. An attacker who holds Item/Configure permission on a job (for example, a non-admin user able to edit sandboxed Pipelines) can plant a malicious classpath entry and wait for any administrator to copy the item or update its config remotely, at which point the entry is silently trusted. This yields arbitrary code execution inside the Jenkins controller JVM, giving the attacker full control over the controller, its credentials, and all jobs. Any Jenkins controller running an affected version of the plugin where non-administrators can define classpath entries is exposed. No public proof-of-concept is known, the flaw is not in the CISA KEV catalog, and no exploitation has been reported.

Do: Upgrade the Script Security Plugin to a release newer than 1415.v9a_f9b_3a_c253d as published in the Jenkins security advisory. Until patched, restrict Item/Configure permission to trusted users, review pending classpath entries in the in-process script approval and classpath approval screens under Manage Jenkins, and refrain from copying items or editing job configurations via REST API or CLI with admin accounts. Audit job configurations for classpath entries submitted by untrusted users.

The Jenkins Script Security Plugin, version 1415.v9a_f9b_3a_c253d and earlier, downloads a JAR file specified by URL twice when validating classpath entries: it confirms the sandbox approval against the first download but loads the classpath entries from the second. An attacker with permission to define classpath entries (for example, a user able to configure sandboxed scripts) can exploit this time-of-check/time-of-use gap by serving benign content for the approval fetch and malicious code for the load. Successful exploitation allows arbitrary code execution in the context of the Jenkins controller JVM, which typically means full compromise of the controller, its builds, and its stored credentials. Any Jenkins controller running an affected version of the plugin is exposed, though the attack requires low-privileged authenticated access and a high-complexity race between the two downloads. No public proof-of-concept or confirmed in-the-wild exploitation is currently known, and the issue is not listed in CISA KEV.

Do: Upgrade the Script Security Plugin to the latest release in the Jenkins update center (any version newer than 1415.v9a_f9b_3a_c253d). In the interim, restrict which users may define classpath entries or run sandboxed scripts (e.g., limit Job/Configure permissions and review script-approval settings), and audit existing classpath entries for URLs pointing to attacker-controllable hosts.

The Jenkins Script Security Plugin fails to apply sandbox checks to calls targeting methods that are added dynamically to a class at runtime, creating a protection-mechanism gap in its Groovy sandbox. An attacker who already has permission to define and run sandboxed scripts, such as Pipelines, can invoke such dynamically added methods to slip past the sandbox approval mechanism. Successful abuse yields execution of arbitrary code outside the sandbox on the Jenkins controller, with high impact to confidentiality, integrity, and availability. Any Jenkins instance running Script Security Plugin version 1415.v9a_f9b_3a_c253d or earlier is affected, though exploitation requires the attacker to hold script-authoring privileges, which is reflected in the high attack-complexity and low-privilege CVSS vector. No public proof of concept and no exploitation in the wild are currently known.

Do: Update the Script Security Plugin to the latest release published in the Jenkins security advisory (any version newer than 1415.v9a_f9b_3a_c253d). Until patched, limit which users or groups can create or run sandboxed scripts and Pipelines, and review recently granted script permissions. Administrators should also audit Pipeline job definitions and run logs for unexpected script activity, keeping in mind the network-reachable but privileged nature of this flaw.

The Jenkins Pipeline: Multibranch Plugin, up to and including version 841.vec5b_9e1806ec, does not set the appropriate context when looking up credentials for the resolveScm Pipeline step, an incorrect-authorization flaw (CWE-863). An attacker who holds Item/Configure permission on a Jenkins item can trigger resolveScm and capture credentials that they are not entitled to access. Because the flaw requires an authenticated user with job-configuration rights, the impact is limited to confidentiality (CVSS 3.1 of 3.1, low), but captured credentials could enable further access to SCM systems or other integrated services. All Jenkins controllers running the plugin at or below the affected version are exposed. No public proof-of-concept or known in-the-wild exploitation has been reported; a patch was issued as part of the Jenkins plugin security release cycle.

Do: Update the Pipeline: Multibranch Plugin to a release newer than 841.vec5b_9e1806ec via the Jenkins plugin manager, following the fixed version listed in the Jenkins security advisory. In the meantime, restrict Item/Configure permission to trusted users and review job configurations and credential bindings for unexpected use of the resolveScm step. Audit which credentials are available to multibranch jobs and rotate any that may have been accessible to lower-privileged users.

The Pipeline: Groovy Libraries Plugin for Jenkins fails to restrict the library path passed to the `library` Pipeline step to a relative path within the SCM checkout, and it follows symbolic links that point outside the checkout, creating a path traversal flaw (CWE-22). An attacker who can configure Pipelines on the Jenkins instance — i.e., an authenticated user with job/pipeline configuration rights — can exploit this via the network. Successful exploitation allows reading files in the resources directory and deleting files in the test directory of the Jenkins controller's file system, partially compromising confidentiality and integrity of the controller. All Jenkins installations running Pipeline: Groovy Libraries Plugin version 805.va_fc79344957d or earlier are affected. No public proof-of-concept is known and the flaw is not listed in CISA KEV; it appears to have been disclosed and patched as part of a recent batch of Jenkins plugin fixes.

Do: Upgrade the Pipeline: Groovy Libraries Plugin to the fixed release published in the Jenkins security advisory (any version later than 805.va_fc79344957d), which was issued alongside a batch of roughly 20 plugin fixes. Until upgraded, restrict which users can create or configure Pipelines, since exploitation requires job/pipeline configuration privileges. Review controller file systems for unexpected deletions in test directories and audit recently modified resources directories for signs of abuse.

The Jenkins Gradle Plugin parses the build log for a build scan link and then connects to that link to retrieve build scan data, even when a Develocity server URL is explicitly configured in the global configuration. An attacker who can influence the build log (for example, a developer or CI job that can emit a crafted scan link) can point Jenkins at an attacker-controlled URL, causing the plugin to send the Develocity access key stored in the global configuration to that host. The attacker gains the access key, which can be used to authenticate to the organization's Develocity server and access its build scan data. Any Jenkins controller running the Gradle Plugin version 2.19.1252.v15196b_5a_6e10 or earlier with a Develocity access key configured globally is affected. No public proof-of-concept or in-the-wild exploitation is currently known, and a patch addressing the issue is available.

Do: Update the Jenkins Gradle Plugin to a release newer than 2.19.1252.v15196b_5a_6e10 via the plugin manager. Rotate any Develocity access key stored in the Jenkins global configuration if builds may have printed untrusted scan links, restrict which users/jobs can control build log output, and audit outbound requests or Develocity logs for connections to unexpected hosts.

Jenkins GitLab Plugin 1.2149.vcfc32c82b_f7f and earlier caches the GitLab API client it builds for alternative GitLab API token credentials using a cache key derived only from the credentials ID, omitting the folder in which the credential was resolved. As a result, when credentials with the same ID exist in different folders, a cached client built with one folder's token can be reused for an item in another folder. An attacker with Item/Configure permission on an item can trigger this and effectively use a GitLab API token credential they are not entitled to, gaining limited unauthorized access to the connected GitLab instance (low confidentiality and integrity impact per the CVSS score of 5.4). Affected users are operators of Jenkins controllers running the GitLab Plugin at or below 1.2149.vcfc32c82b_f7f, particularly multi-folder setups that use folder-scoped credentials sharing IDs. Exploitation has not been observed in the wild, no public proof-of-concept is known, and the issue is not listed in CISA's KEV catalog.

Do: Update the Jenkins GitLab Plugin to the first patched release after 1.2149.vcfc32c82b_f7f (fixes were shipped alongside Jenkins' batch advisory covering 20 plugin vulnerabilities). Meanwhile, audit folder-scoped GitLab API token credentials for colliding IDs across folders and restrict Item/Configure permission to trusted users. Check GitLab audit logs for unexpected API activity that could indicate a token was used without authorization.

The Jenkins Warnings Plugin fails to validate the analysis results ID when a job configuration is submitted, including through the REST API. An attacker holding Item/Configure permission on a job can set the identifier to a URL using the javascript: scheme, which is then stored and rendered to other users, executing as a stored cross-site scripting (XSS) attack. Successful exploitation lets the attacker run arbitrary JavaScript in the browsers of other Jenkins users, enabling actions taken as the victim, session hijacking, and potential exposure of credentials or data readable in the victim's session (CVSS 8.0 high). Any Jenkins controller running Warnings Plugin 13.10258.va_17d49a_78c3b_ or earlier is affected, with the highest risk where Configure permissions are broadly granted or the REST API is used for job management. No public proof-of-concept or exploitation in the wild is currently known, and the flaw is not listed in CISA's KEV catalog.

Do: Upgrade the Jenkins Warnings Plugin to the newest release published after this advisory (versions 13.10258.va_17d49a_78c3b_ and earlier are vulnerable). In the meantime, limit Item/Configure permission to trusted users and restrict REST API access to job configuration. Audit existing job configurations for analysis results IDs set to javascript: or other unexpected URL schemes and remove them.

The Jenkins Coverage Plugin fails to validate the coverage results ID supplied when a job configuration is submitted through the REST API, allowing an attacker with Item/Configure permission to store a URL using the javascript: scheme as the identifier. When other users subsequently view pages where that stored identifier is rendered, the embedded script executes in their browser session. Successful exploitation gives the attacker arbitrary script execution as the victim user, which can be used to steal sessions or credentials, modify Jenkins configurations, or perform actions with the victim's privileges. All Jenkins instances running Coverage Plugin 3.3358.v9487dde48783 or earlier are affected. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is currently known.

Do: Upgrade the Coverage Plugin to a fixed release newer than 3.3358.v9487dde48783 as soon as it is available. Until then, restrict Item/Configure permission to trusted users only and audit existing job configurations (via the REST API or UI) for javascript: URLs in the coverage results ID field, removing any that are found. Treat unexpected coverage ID changes as suspicious, since this permission is normally limited to authorized project configurators.

The OWASP Dependency-Check Plugin for Jenkins up to and including version 5.6.4 fails to escape CWE values taken from Dependency-Check reports before rendering them in the Jenkins UI, enabling a stored cross-site scripting (XSS) vulnerability. An attacker who already holds Item/Configure permission on a Jenkins job can inject a malicious payload into the report data so that it persists and executes whenever other users view the report in the web interface. A successful attack lets the attacker run arbitrary script in the victim's browser session, potentially hijacking sessions and performing actions with the victim's Jenkins privileges. Any Jenkins controller running the affected plugin is exposed, particularly multi-user controllers where report viewers are not the same users who configure jobs. No exploitation in the wild or public proof-of-concept is currently known.

Do: Update the OWASP Dependency-Check Plugin to the latest patched release available from the Jenkins update center (all versions 5.6.4 and earlier are affected). Limit Item/Configure permission to trusted users and review recent job configuration changes for unexpected report content. Treat viewing of Dependency-Check reports in the Jenkins UI with caution until the plugin is patched.

The Robot Framework Plugin for Jenkins, version 6.2.2 and earlier, fails to verify that the archive directory configured for Robot Framework report files is contained within the build directory on the Jenkins controller (a path traversal flaw, CWE-22). An attacker who holds Item/Configure permission on any job can set an archive directory pointing outside the build directory and thereby create or replace arbitrary files on the controller file system with attacker-specified content. By overwriting sensitive files, the attacker can achieve remote code execution on the Jenkins controller. Any Jenkins instance running the affected plugin is exposed, particularly where Item/Configure permission is granted to broad or partially trusted user groups. No public proof-of-concept is known and the flaw is not listed in CISA's Known Exploited Vulnerabilities catalog, so exploitation has not been confirmed.

Do: Upgrade the Robot Framework Plugin to a fixed release newer than 6.2.2 as soon as it is published, and review Jenkins security advisories for the exact fixed version. Until then, restrict Item/Configure permission to fully trusted users only, and audit existing job configurations for archive directory paths that escape the build directory. Check the Jenkins controller file system for unexpected or recently modified files that could indicate abuse.

The OAuth authorization endpoint in the Jenkins Bitbucket Server Integration Plugin 6.0.1 and earlier fails to verify the authenticity of the callback parameter (CWE-345): it takes the `oauth_callback` URL from the submitted form rather than using the callback stored server-side with the request token. An attacker can craft an authorization request whose callback points to a location they control and, with the victim completing the OAuth flow (user interaction is required), hijack the authorization and obtain an access token on the victim's behalf. With that token the attacker gains whatever access the victim's Bitbucket account grants the integration, such as reading repository content or interacting with the linked Bitbucket Server. Any Jenkins instance running the plugin at version 6.0.1 or earlier is affected. No public proof-of-concept or confirmed in-the-wild exploitation is known; the flaw carries a medium CVSS 3.1 score of 4.2, reflecting high attack complexity and low confidentiality/integrity impact.

Do: Update the Bitbucket Server Integration plugin to the first fixed release after 6.0.1 via the Jenkins plugin manager. Administrators should review and revoke or rotate Bitbucket OAuth access tokens issued through the integration and check for suspicious authorization events. Restrict network access to the Jenkins OAuth endpoints where possible.

The Jenkins Bitbucket Push and Pull Request Plugin 4.0.1 and earlier blindly trusts values supplied in a webhook payload, including certain URLs, and then connects to those attacker-controlled URLs using the Bitbucket credentials configured in Jenkins (CWE-918, server-side request forgery). An unauthenticated attacker who can reach the plugin's webhook endpoint can send a crafted payload pointing at a server they control, causing Jenkins to authenticate to that server and thereby reveal the stored Bitbucket credentials. Successful exploitation gives the attacker the Bitbucket credentials held in Jenkins, which can lead to unauthorized access to the connected source code repositories. Any Jenkins controller running the plugin at version 4.0.1 or earlier is affected, provided the webhook endpoint is reachable and Bitbucket credentials are configured. As of now there is no known exploitation, no public proof-of-concept, and the issue is not listed in CISA's KEV.

Do: Update the Bitbucket Push and Pull Request Plugin to the latest fixed release, since 4.0.1 and earlier are vulnerable. Until updated, restrict network access to the plugin's webhook endpoint to trusted Bitbucket sources and check logs for outbound connections to unexpected URLs or unusual use of the configured Bitbucket credentials. If compromise is suspected, rotate the Bitbucket credentials stored in Jenkins.

The Jenkins Gitee Plugin fails to escape the sender name taken from Gitee push webhook payloads when it is rendered in build causes, allowing malicious script to be stored in Jenkins. An attacker who is able to trigger builds through the plugin's webhook endpoint can submit a crafted Gitee push payload whose sender name contains JavaScript. When a Jenkins user later views the affected build cause, the injected script runs in their browser session, potentially enabling credential theft or unauthorized actions in the Jenkins UI (CVSS rates confidentiality, integrity and availability impacts as high, though user interaction and high privileges are required). Any Jenkins instance running Gitee Plugin version 1301.v8957053c7902 or earlier is affected. No public proof-of-concept is known, the flaw is not in CISA's KEV catalog, and there are no reports of exploitation in the wild.

Do: Update the Gitee Plugin to the newest release published after 1301.v8957053c7902 (see the corresponding Jenkins security advisory). Until then, restrict the webhook endpoint to trusted Gitee sources (e.g., require authentication or network allow-listing) and treat build cause data as untrusted. Check Jenkins instances for the plugin via the plugin manager and review recent builds triggered by the Gitee webhook for suspicious sender names.

CVE-2026-92141 is an open redirect flaw (CWE-601) in the Jenkins Keycloak Authentication Plugin version 2.4.1 and earlier, which fails to restrict the URL a user is redirected to after logging in. An attacker can craft a link that sends a victim through the Jenkins Keycloak login flow and then redirects them to an attacker-controlled site. Because the redirect follows a successful login, victims may perceive the destination page as legitimate, enabling convincing phishing attacks that harvest credentials or other sensitive information. Any Jenkins instance running the plugin at version 2.4.1 or earlier is affected. No public proof-of-concept is known, the issue is not listed in CISA KEV, and there are no confirmed reports of exploitation in the wild.

Do: Upgrade the Keycloak Authentication Plugin to a release newer than 2.4.1 as directed by the Jenkins security advisory. Until patched, alert Jenkins users to verify the destination URL after logging in and be wary of phishing lures that link through Jenkins authentication pages. Administrators should audit plugin update centers and Jenkins controller logs for unexpected post-login redirects.