A bouncer checks IDs at the door but lets you in wearing someone else's jacket because the name tag matches
Jenkins Script Security Plugin implements a Groovy sandbox that intercepts method calls to prevent untrusted scripts from invoking dangerous operations. This flaw occurs when a sandboxed script coerces a value to an interface, and the resulting proxy does not verify methods inherited with the same name. An attacker who can define and run a sandboxed Pipeline can craft a type collision that slips through the proxy and executes arbitrary code directly in the Jenkins controller JVM. Affected versions are Script Security Plugin 1415.v9a_f9b_3a_c253d and earlier; Jenkins bundles the plugin by default.
Vendor labels this HIGH 8.8, but that undersells the role. Jenkins controllers are CI/CD orchestrators—they hold deployment credentials, source control tokens, and artifact signing keys. Code execution on the controller is a supply-chain pivot, not just a single host compromise. The only friction is that the attacker needs a low-privileged Jenkins account with script/Pipeline permissions; in many enterprise Jenkins installations that is every developer. The vendor score is a fair starting point for a generic authenticated RCE, but the noisgate deployment-role analysis floors this at CRITICAL.
5 steps from start to impact.
Authenticate to Jenkins with script/Pipeline permissions
Job/Build or Job/Configure. This can be achieved with stolen credentials, a low-privilege internal account, or via SSO misconfiguration. Public Jenkins instances may offer self-registration in some configurations, but most are internal.- Valid Jenkins credentials
Overall/ReadplusJob/BuildorJob/Configure- Ability to create or edit a Pipeline job or commit to a Jenkinsfile source repo
- Jenkins controllers are usually behind VPN or SSO, not public
- Org policies may restrict Pipeline creation to admins
- Account lockout / MFA can block credential stuffing
Define a malicious sandboxed Pipeline
Job/Configure.- Path to define a Pipeline:
Job/Configureor SCM commit access - Sandbox mode enabled (often default for Pipeline)
- Many jobs use declarative Pipeline with limited Groovy; malicious script must be in script step
- Code review or branch protections on Jenkinsfile repos can catch injection
- Some orgs disable inline Pipeline scripts
Trigger interface coercion and proxy method collision
- Vulnerable Script Security Plugin version ≤ 1415.v9a_f9b_3a_c253d
- A crafted combination of Groovy value and interface with matching method names
- No public PoC lowers immediate mass exploitation
- Not all interface/type pairs work; attacker must understand the exact proxy behavior
Execute arbitrary code in the Jenkins controller JVM
- Controller JVM has a service account with privileged access
- No additional network movement needed—the JVM is already on the controller host
- Containerized Jenkins controllers limit host breakout but not credential theft
- EDR on the controller host may detect child process or memory tampering
Pivot to source repos, cloud, and deployment targets
- Jenkins credential stores contain secrets for production systems
- Pipeline definitions are editable and trigger on future runs
- Secrets may be scoped to folders, limiting blast radius
- Credential store may be external Vault with short-lived tokens
- GitOps/SBOM controls may detect unexpected artifacts
Job/Build and Job/Configure to trusted engineers immediately — This removes the initial permission required to define and run sandboxed scripts. Apply within 3 days (noisgate mitigation SLA for CRITICAL). On Jenkins, deny these permissions to broad developer groups and audit existing users.Job/Build from injecting arbitrary Groovy; changes require SCM commit and code review. Deploy within 3 days.- Relying on the Groovy sandbox — it is exactly what is bypassed.
- WAF or network segmentation alone — does not stop authenticated HTTP requests to Jenkins job creation.
- Disabling script approval — the vulnerability bypasses method checks, so approval lists won't block the proxy issue.
The supporting signals.
| KEV status | Not listed in CISA KEV; no active exploitation evidence as of 2026-09-21. |
|---|---|
| In-the-wild status | No known campaigns; the flaw is a sandbox bypass and would be used post-authentication. |
| Public PoC | None observed on pocindex.io, GitHub, or ExploitDB as of 2026-09-21; exploitation is a custom Groovy sandbox escape. |
| EPSS | 0.00632 (0.63% likelihood of exploitation in next 30 days). |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8 HIGH. |
| Affected versions | Script Security Plugin ≤ 1415.v9a_f9b_3a_c253d; Jenkins core bundles the plugin by default. |
| Fixed versions | None publicly available as of 2026-09-21; track the Jenkins Security Advisory for the patched plugin. |
| Exposure | Jenkins controllers should not be internet-facing; no specific Shodan/Censys telemetry was provided, but most installs are internal CI/CD. |
| Disclosure date | 2026-09-16 (CVE published). |
| Reporter | Not disclosed in the CVE record or available search results. |
Sources.
Why this verdict
- Role multiplier: Jenkins controllers are canonical CI/CD orchestrators; successful RCE on the controller JVM yields credential theft, source repo access, and supply-chain pivot across pipelines and artifacts. This meets the CRITICAL floor for high-value-role components.
- Privilege level is misleading: CVSS 8.8 assumes low privileges, but typical enterprise Jenkins gives hundreds of developers
Job/BuildorJob/Configure, making the attacker population large once credentials are obtained. - No patch available: No vendor fix was published as of 2026-09-21, so mitigation must rely on permission lockdown, which is a temporary and imperfect control for a CRITICAL severity.
Why not higher?
The chain requires a valid Jenkins account with script/Pipeline permissions; it is not unauthenticated and cannot be scripted into an internet-wide worm. No public PoC or active exploitation has been observed as of 2026-09-21, so a 9.5+ score is not warranted.
Why not lower?
The vulnerable component is the Jenkins controller, not a sandboxed agent or worker. Complete sandbox bypass to arbitrary code in the controller JVM can exfiltrate CI/CD secrets and modify artifact pipelines across the fleet. Only the pre-authentication requirement stops this from being a 10.0.
Crowdsourced verification payload.
Run this bash script on the Jenkins controller host with read access to $JENKINS_HOME. Invoke with the Jenkins home directory as the only argument: ./check_cve-2026-92122.sh /var/lib/jenkins. Requires filesystem read permission, not root unless Jenkins home is restricted. Outputs VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env bash
set -euo pipefail
vulnerable='1415.v9a_f9b_3a_c253d'
jenkins_home=${1:-/var/lib/jenkins}
manifest=$jenkins_home/plugins/script-security/META-INF/MANIFEST.MF
if [[ ! -f $manifest ]]; then
echo UNKNOWN; exit 3
fi
version=$(grep -E '^Plugin-Version:' $manifest | head -n1 | awk '{print $2}' | tr -d '\r')
if [[ -z $version ]]; then
echo UNKNOWN; exit 3
fi
if [[ $version == $vulnerable ]]; then
echo VULNERABLE; exit 1
fi
if command -v sort >/dev/null && sort --version 2>/dev/null | grep -q GNU; then
if [[ $(printf '%s\n' $vulnerable $version | sort -V | head -n1) != $vulnerable ]]; then
echo VULNERABLE; exit 1
else
echo PATCHED; exit 0
fi
else
vuln_num=${vulnerable%%.*}
ver_num=${version%%.*}
if (( 10#$ver_num <= 10#$vuln_num )); then
if (( 10#$ver_num < 10#$vuln_num )); then
echo VULNERABLE; exit 1
fi
vuln_suffix=${vulnerable#*.}
ver_suffix=${version#*.}
if [[ $(printf '%s\n' $vuln_suffix $ver_suffix | sort | head -n1) != $vuln_suffix ]]; then
echo VULNERABLE; exit 1
else
echo PATCHED; exit 0
fi
else
echo PATCHED; exit 0
fi
fi