Jenkins Script Security Has Multiple Sandbox Escapes — Pipelines Can Reach the Controller JVM

• The Mess: Jenkins just patched a nasty cluster of vulnerabilities in Script Security Plugin. Eight separate flaws let attackers who can define and run sandboxed Groovy scripts bypass protections that are supposed to keep those scripts away from arbitrary controller-side code execution.
• The Damage: This is not a browser bug or a harmless crash — a successful sandbox escape can turn an allowed Pipeline or sandboxed script into arbitrary code execution inside the Jenkins controller JVM.
• The Fix: Upgrade Script Security Plugin to 1422.v06869826dd9b_ immediately and treat older versions as exposed.

Jenkins’ Script Security Plugin exists for one very specific reason: sandbox untrusted Groovy code.

That matters because Jenkins Pipelines routinely execute code supplied by developers, repositories, pull requests and automation jobs. The sandbox is supposed to intercept dangerous operations before they reach the controller JVM.

The September 16 advisory shows just how much attack surface sits inside that interception layer.

The vulnerable range is Script Security Plugin 1415.v9a_f9b_3a_c253d and earlier. The fixed release is 1422.v06869826dd9b_.

Eight different ways around the sandbox

The advisory lists multiple high-severity vulnerabilities rather than one isolated implementation mistake.

CVE-2026-92122 abuses Groovy interface coercion. A generated proxy could invoke an inherited method without the Script Security checks properly validating the call.

CVE-2026-92123 targets operations performed on a null receiver. Method calls, property access and array access involving null were not intercepted correctly.

CVE-2026-92124 abuses collection casting. The plugin checked operations involving collection elements, but Groovy could perform the actual cast against the collection itself, allowing different elements to be processed.

CVE-2026-92125 abuses @GroovyASTTransformationClass. The annotation can cause Groovy to execute an AST transformation during compilation — before the sandbox is applied.

CVE-2026-92126 targets Groovy’s @Builder annotation. A sandboxed script could reference an arbitrary builder strategy class, potentially causing code to execute before sandbox enforcement. Jenkins describes successful exploitation as requiring a suitable class on the evaluator’s classpath.

Then the attack surface gets uglier.

Classpath loading is another escape hatch

CVE-2026-92127 affects Script Security’s classpath approval mechanism.

Jenkins allows Groovy scripts to load classes from JAR files, but administrators are supposed to approve those classpath entries first.

The vulnerable plugin could automatically approve classpath entries when an item was copied or its configuration was modified through REST API or CLI by an administrator.

That can result in arbitrary code execution in the controller JVM when an attacker can control the classpath entries.

CVE-2026-92128 attacks the same general area through a TOCTOU race.

The plugin downloaded a URL-specified JAR twice during evaluation. The first download was used for approval, while the second was loaded.

If an already-approved JAR is served from infrastructure controlled by an attacker, the content can change between the security check and actual use.

That is a classic time-of-check/time-of-use problem. Jenkins fixed it by downloading the URL only once.

And then there is CVE-2026-92129.

Groovy allows classes to gain additional methods dynamically. Script Security did not properly check calls to those dynamically added methods from sandboxed scripts.

The attacker still needs those methods to have been defined by code running outside the sandbox — for example, a plugin — but once that condition exists, the sandbox boundary can be bypassed.

This is why Jenkins controllers matter

The important part isn’t merely that eight CVEs exist.

The important part is where the resulting code executes.

Jenkins describes the impact of the sandbox bypasses as arbitrary code execution in the context of the Jenkins controller JVM.

That controller is normally connected to the infrastructure Jenkins is responsible for automating.

Depending on deployment architecture, that can mean access to:

• Jenkins credentials
• SCM tokens
• cloud credentials
• deployment secrets
• build artifacts
• internal APIs
• agent infrastructure
• filesystem content
• other jobs and pipelines

The exact post-exploitation impact depends on Jenkins permissions, credential configuration and network segmentation. The CVEs themselves do not magically grant every possible privilege in every installation.

But once arbitrary code executes inside the controller JVM, the security boundary has already failed.

The attacker still needs Jenkins permissions

There is an important qualification.

These vulnerabilities are not described by Jenkins as anonymous unauthenticated RCE.

The sandbox bypasses generally require an attacker to have permission to define and run sandboxed scripts, including Pipelines.

That distinction matters.

A public Jenkins instance with anonymous access disabled but with a large number of developers allowed to create or modify Pipelines has a different exposure model from a tightly locked-down controller where only a few administrators can define executable jobs.

Jenkins explicitly identifies the required permission level in its descriptions.

The attack therefore looks less like:

Internet → Jenkins → RCE

and more like:

Jenkins account / Pipeline capability → sandbox bypass → controller JVM → Jenkins infrastructure

That is still a serious boundary failure.

The fix is unusually clean

Jenkins fixed the affected Script Security vulnerabilities in:

1422.v06869826dd9b_

The Jenkins plugin repository lists that version as released on September 9, 2026.

The Jenkins advisory explicitly states that Script Security Plugin should be upgraded to 1422.v06869826dd9b_ and considers previous versions affected unless otherwise indicated.

Administrators should therefore check the installed plugin version rather than assuming that updating Jenkins core automatically solved the problem.

That’s particularly important because Jenkins is a plugin-heavy platform. Core and plugin versions move independently.

Don’t stop at Script Security

The September 16 Jenkins advisory covers 20 vulnerabilities across 13 plugins.

The same release also includes the Robot Framework Plugin path traversal we covered separately, where an attacker with Item/Configure can manipulate the report archive location and write arbitrary files to the controller filesystem. Jenkins states that this can lead to RCE.

Other affected plugins include Pipeline: Multibranch, Pipeline: Groovy Libraries, GitLab, Gradle, Bitbucket integrations, Coverage, Gitee, Warnings and OWASP Dependency-Check.

So this is not a situation where an administrator should update one plugin and close the ticket.

The entire September 16 advisory deserves a pass.

What Jenkins admins should do now

1. Check the installed Script Security Plugin version.
2. Upgrade to 1422.v06869826dd9b_ or newer.
3. Review which users can create or modify Pipelines and sandboxed scripts.
4. Audit recent Pipeline and job configuration changes.
5. Review controller logs for unexpected job executions or administrative activity.
6. Check other plugins listed in the September 16 advisory.
7. Treat Jenkins controller credentials as high-value secrets and avoid unnecessary credential exposure to jobs.
8. Keep controller and agents separated as much as the architecture allows.

The permission review is especially important. A sandbox only provides meaningful isolation if the code entering that sandbox cannot escape it.

Bugstoday’s take

Jenkins’ sandbox is supposed to be the fence around untrusted automation.

This advisory shows eight different places where that fence had holes: Groovy coercion, null handling, collection casting, AST transformations, builder strategies, classpath approval, JAR loading races and dynamically added methods.

None of these bugs needs an unauthenticated attacker to be dangerous.

The real question for Jenkins operators is simpler: who can run code?

If that answer includes developers, external contributors, pull-request automation or other semi-trusted users, Script Security is part of the security boundary — not just another plugin.

Patch it.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• Jenkins Security Advisory 2026-09-16
• Jenkins Script Security Plugin release history
• CVE-2026-92122
• CVE-2026-92123
• CVE-2026-92124
• CVE-2026-92125
• CVE-2026-92126
• CVE-2026-92127
• CVE-2026-92128
• CVE-2026-92129