Jenkins Script Security 1422: Eight Fixes for Pipeline Sandbox Escapes

On 16 September 2026 the Jenkins project published an advisory covering 13 plugins and 20 CVE IDs. Eight of those CVEs are in Script Security Plugin, the component that sandboxes Groovy in Pipelines, and most of them let a user who can define and run sandboxed scripts break out and execute code in the Jenkins controller JVM.

The timing matters. Script Security 1415.v9a_f9b_3a_c253d was the fixed version in Jenkins' 2 September advisory. Two weeks later, that same version is listed as affected. Teams that patched promptly in early September need to patch again.

What's affected

Script Security Plugin 1415.v9a_f9b_3a_c253d and earlier. Fixed in 1422.v06869826dd9b_. All eight issues below are rated High by the Jenkins project:

• CVE-2026-92122: Groovy interface coercion creates a proxy that forwards calls to same named methods; the sandbox did not check the method the proxy actually calls.
• CVE-2026-92123: operations on a null receiver (method calls, property and array access) were not intercepted.
• CVE-2026-92124: collection casts were checked on the elements read, but performed on the collection itself, so an overridden collection could swap elements.
• CVE-2026-92125: @GroovyASTTransformationClass was not rejected, letting a script trigger an arbitrary AST transformation at compile time, before the sandbox applies.
• CVE-2026-92126: @Builder with an arbitrary builderStrategy class could be instantiated at compile time. The advisory says this needs a suitable class on the classpath.
• CVE-2026-92127: classpath entries were auto approved when an administrator copied an item or updated it through the REST API or CLI.
• CVE-2026-92128: a time of check to time of use race where a JAR given by URL was downloaded twice, once to check approval and once to load. Exploitation needs an already approved JAR served from an attacker's server.
• CVE-2026-92129: calls to methods added to classes at runtime were not checked. This needs those methods to have been defined outside the sandbox, for example by a plugin.

The same advisory fixes other plugins that CI teams commonly run:

Warnings, Coverage, OWASP Dependency-Check and Gitee also received stored XSS fixes, and Keycloak Authentication 2.4.2 fixes an open redirect.

How to check if you're exposed

Run this in the Script Console of each controller to print the versions that matter:

def watch = ['script-security','robot','bitbucket-push-and-pull-request',
             'pipeline-groovy-lib','workflow-multibranch','gradle',
             'gitlab-plugin','atlassian-bitbucket-server-integration',
             'warnings-ng','coverage','dependency-check-jenkins-plugin',
             'gitee','keycloak']
Jenkins.instance.pluginManager.plugins
  .findAll { it.shortName in watch }
  .each { println "${it.shortName}:${it.version}" }

If you manage controllers as code, check your plugins.txt for the same names. Then ask the question that decides urgency: who can define Pipelines? On many instances, anyone who can push a Jenkinsfile to a branch that a multibranch job builds can run sandboxed Groovy. For these CVEs, that is the attacker.

What to do now

1. Update Script Security to 1422.v06869826dd9b_ on every controller, even if you updated to 1415 in early September.
2. Update the other plugins in the table, prioritizing Robot Framework (file write on the controller) and Bitbucket Push and Pull Request (credential capture through the webhook at /bitbucket-hook/).
3. Check for broken Pipelines after the upgrade. The advisory notes that sandboxed scripts can no longer refer to Groovy's builder strategies through a star import, though fully qualified names and single class imports still work.
4. Review pending and approved script and classpath approvals under In process Script Approval, given CVE-2026-92127 and CVE-2026-92128.
5. Limit who can run Pipelines from untrusted branches. Builds from forks and outside contributors should not run arbitrary Groovy on the controller.
6. Enforce Content Security Policy on Jenkins 2.539 or newer (LTS 2.541.1 or newer), which the advisory says mitigates the Warnings, Coverage and Dependency-Check XSS issues.

Why it matters

The Groovy sandbox has to intercept every potentially unsafe operation in an extremely dynamic language. Coercion, null receivers, compile time annotations and runtime metaclass changes are all ways Groovy does work that the sandbox has to anticipate. Six of the eight Script Security fixes in this advisory are distinct sandbox bypasses, published two weeks after the previous Script Security fix.

The practical lesson for platform teams is to treat "can write a Jenkinsfile" as close to "can run code on the controller", and design permissions accordingly. Pairing that with a plugin update cadence measured in days, not quarters, is what keeps a sandbox escape from turning into credential theft across every job.

Try it yourself

Take your controller's plugins.txt (or the Script Console output above) and diff it against the fixed versions in the advisory. Then list every job that builds branches from people outside your team. That list is your sandbox exposure.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Jenkins Security Advisory 2026-09-16
• Jenkins Security Advisory 2026-09-02
• Jenkins security advisories index