Jenkins Script Security Sandbox Bypass Leading to RCE (CV...

In February 2019, the Jenkins security team disclosed CVE-2019-1003029, a sandbox bypass vulnerability in the Script Security plugin that allowed attackers to escape the Groovy sandbox and achieve remote code execution (RCE) on the Jenkins controller. The flaw sat in a foundational piece of Jenkins infrastructure: the sandbox that is supposed to let low-privileged users write and run Groovy pipeline scripts without being able to touch the underlying JVM, file system, or shell. When that sandbox can be bypassed, any user with permission to define a scripted Pipeline effectively gains code execution on the build server itself — a direct path to credential theft, artifact tampering, and full CI/CD compromise.

Jenkins is the most widely deployed open-source automation server in the world, and the Script Security plugin is the component nearly every other scripting-capable plugin depends on for sandboxing untrusted Groovy. That includes Pipeline: Groovy, Pipeline: Declarative, Job DSL, and a long list of plugins that expose a "sandboxed" checkbox to non-administrator users. CVE-2019-1003029 is a good case study in why sandbox-based security models are so fragile in a language as dynamically flexible as Groovy — and why supply chain security programs need visibility into exactly which build infrastructure versions are running, not just which ones are nominally "supported."

What CVE-2019-1003029 Actually Is

Script Security's sandbox works by intercepting method calls, field accesses, and constructor invocations made by a Groovy script and checking each one against a whitelist before allowing it to execute. The intent is that a script can be marked "sandboxed" and run by a non-admin user, with the plugin guaranteeing that only pre-approved, safe operations are reachable.

CVE-2019-1003029 was one of a cluster of sandbox bypass issues Jenkins disclosed together in its February 2019 security advisory. The underlying problem was that Groovy's runtime offers multiple, semantically equivalent ways to reach the same underlying method — through property access, operator overloading, closures, method pointers, and type coercion — and the sandbox's interception logic did not cover every one of those paths consistently. An attacker who could author a Groovy pipeline script (even one restricted to "sandbox mode") could construct a call that reached an unvetted method or constructor outside the whitelist, stepping outside the sandbox boundary entirely. From there, the script runs with the same privileges as the Jenkins process, which on most installations means it can execute arbitrary shell commands, read credentials from the Jenkins credential store, or modify other jobs.

This is precisely why script security and Groovy pipeline sandboxing are such high-value targets: a single successful bypass converts a "low privilege, job-configuration" permission into full controller compromise, and Jenkins controllers routinely hold secrets, deployment keys, and access to production infrastructure.

Affected Versions and Components

CVE-2019-1003029 affects the Script Security plugin for Jenkins in versions prior to the fix released alongside the February 2019 advisory. Because Script Security underpins the sandbox used by other plugins, the practical blast radius extends to anything that relies on it for Groovy execution, most notably:

• Pipeline: Groovy plugin — the plugin that actually executes scripted and declarative Jenkinsfile pipeline code
• Pipeline: Declarative plugin — which compiles declarative syntax down through the same Groovy/CPS execution path
• Any other plugin (Job DSL, Groovy plugin scripts, email-ext templates, etc.) that offers a sandboxed script execution mode backed by Script Security

Jenkins shipped fixed releases of Script Security and the affected Pipeline plugins as part of the same advisory that addressed CVE-2019-1003029, tightening the interception rules that govern method dispatch, casting, and closure execution inside the sandbox. Any Jenkins instance still running a pre-fix Script Security plugin, regardless of Jenkins core version, remains exposed. Because plugin updates are decoupled from Jenkins core upgrades, it's entirely possible to be running the latest Jenkins LTS release while still carrying a vulnerable, years-old Script Security plugin — a mismatch we see constantly in supply chain assessments.

Severity, CVSS, and Exploitability Context

Jenkins' own advisory classified this batch of sandbox bypass issues as high severity, reflecting the fact that exploitation requires only the ability to configure a job or submit a pipeline script — a permission level ("Job/Configure" or equivalent) that many organizations grant broadly to developers — and results in complete compromise of the Jenkins controller. NVD lists a CVSS v3 base score in the high range (8.8) for this vulnerability, consistent with a network-exploitable issue that needs low privileges, no user interaction, and yields a full loss of confidentiality, integrity, and availability on the affected system.

CVE-2019-1003029 does not currently appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and we're not aware of a widely publicized in-the-wild exploitation campaign specifically tied to this CVE. That said, Jenkins sandbox bypasses as a class have a long, well-documented history of being chased by red teamers and abused by attackers who already have some foothold (a compromised developer account, a malicious pull request that triggers a pipeline build, or an insider with job-configuration rights) as a stepping stone to full controller takeover. Low observed EPSS activity on an individual CVE from 2019 is common simply because of its age — it doesn't mean an unpatched, internet-facing Jenkins instance running a seven-year-old Script Security plugin is low risk today. If anything, older Jenkins sandbox bypass CVEs are attractive precisely because so many long-lived, infrequently patched Jenkins controllers are still running vulnerable plugin versions.

Disclosure Timeline

• February 6, 2019 — The Jenkins project publishes a security advisory disclosing a cluster of Script Security and Pipeline plugin sandbox bypass vulnerabilities, including CVE-2019-1003029, alongside fixed plugin releases.
• Post-disclosure — NVD ingests the advisory and publishes the CVE record with associated scoring; security vendors and the Jenkins community begin flagging outdated Script Security installs during audits.
• Ongoing — Because Script Security sandbox bypasses have recurred across multiple Jenkins advisories (both before and after this one), CVE-2019-1003029 is best understood as part of an ongoing pattern rather than a single isolated defect — reinforcing that sandbox-based Groovy execution should never be the sole control protecting a Jenkins controller.

Remediation Steps

1. Update the Script Security plugin to the fixed version referenced in the February 2019 Jenkins security advisory or later, and update Pipeline: Groovy and Pipeline: Declarative plugins to their corresponding fixed releases at the same time — partial updates can leave gaps.
2. Audit plugin inventory across every Jenkins controller, not just the ones you remember. Script Security is a transitive dependency for many plugins, so a controller can be vulnerable even if nobody explicitly installed "Script Security" on purpose.
3. Tighten who can author pipeline scripts. Restrict Job/Configure and script-approval permissions to trusted users, and avoid relying on the sandbox as your only trust boundary — treat sandboxed Groovy pipeline execution as a convenience feature, not a hard security guarantee.
4. Enable and monitor the in-process Script Approval queue so administrators see when scripts request access to non-whitelisted methods, which can surface both legitimate needs and active bypass attempts.
5. Isolate Jenkins controllers from sensitive networks and credentials where possible, and run untrusted or externally triggered builds on agents rather than the controller itself, limiting the damage a successful sandbox escape can do.
6. Patch consistently going forward. Because sandbox bypasses in Script Security have been reported repeatedly over the years, subscribe to Jenkins security advisories and apply plugin updates on a regular cadence rather than only after a headline CVE.

How Safeguard Helps

Vulnerabilities like CVE-2019-1003029 are exactly the kind of risk that hides in plain sight inside CI/CD infrastructure: a plugin nobody thinks about, buried several dependency layers under the Jenkinsfile a team writes every day. Safeguard's software supply chain security platform is built to catch that gap before it becomes an incident.

Safeguard continuously inventories the plugins and versions running across every Jenkins controller and agent in your environment, correlates them against known CVEs like CVE-2019-1003029, and flags outdated Script Security, Pipeline: Groovy, and other Groovy-pipeline-dependent components regardless of whether Jenkins core itself is up to date. Rather than a point-in-time scan, Safeguard tracks drift over time, so a plugin that silently falls out of date after a new sandbox bypass advisory ships gets surfaced immediately, with prioritization that accounts for exploitability signals like CVSS, EPSS, and KEV status rather than raw CVE count.

Beyond detection, Safeguard maps CI/CD risk back to the permissions and trust boundaries that make sandbox bypasses dangerous in the first place — who can configure jobs, which pipelines run with elevated credentials, and which controllers are reachable from less-trusted networks. That context turns a generic "update your plugins" alert into an actionable remediation plan, helping security and DevOps teams close the gap between a Jenkins security advisory and a genuinely hardened build pipeline.