Jenkins Script Security CVE-2026-92123

Requires an authenticated Jenkins user who holds permission to define and run sandboxed scripts, including Pipelines (typically Job/Configure or equivalent Pipeline-authoring rights). The flaw is inherent to the default Script Security sandbox behavior - no non-default configuration is needed on the target; the plugin (versions 1415.v9a_f9b_3a_c253d and earlier) simply fails to intercept operations on a null receiver. Limiting factors: the attacker must already be able to submit sandboxed Groovy/Pipeline scripts, so exposure is highest in multi-tenant or delegated Jenkins instances where script-authoring is granted to less-trusted users, and minimal where only trusted administrators author Pipelines. No user interaction beyond the attacker's own script submission is required.

This is a genuine, high-quality-signal sandbox-escape-to-RCE flaw, but its real-world urgency is moderated by an access prerequisite. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, score 8.8) shows network reach, low complexity, and total CIA impact, but PR:L confirms the attacker must already hold a Jenkins account with permission to author and run sandboxed scripts/Pipelines - this is not an unauthenticated internet-facing bug. CISA SSVC reinforces the nuance: Technical Impact is 'total' (arbitrary code on the controller JVM), yet Exploitation is 'none' (no observed exploitation) and Automatable is 'no' (cannot be reliably mass-exploited, consistent with the authenticated, per-instance permission gate). There is no CISA KEV listing, no public POC, and no EPSS score supplied. The signals are internally consistent rather than conflicting: high impact + real privilege requirement + no current exploitation = a patch-promptly issue for anyone running Jenkins with untrusted Pipeline authors, but not an emergency drop-everything scenario. The one debatable metric is Scope: a sandbox escape arguably crosses a security boundary (S:C), which would push the score higher; the vendor kept S:U. Bottom line: real priority in multi-tenant/shared Jenkins environments where script-authoring permission is delegated broadly; lower practical risk where only trusted admins can author Pipelines.

An attacker who already holds a low-privilege Jenkins account permitted to define and run sandboxed Pipeline scripts writes a Groovy script that performs an operation (method call, property/attribute access, or array access) on a null receiver, which Script Security fails to intercept. This escapes the Groovy sandbox and executes arbitrary code in the Jenkins controller JVM, giving full control of the CI/CD server and its stored credentials. No public exploit code has been identified at time of analysis, and CISA SSVC rates exploitation as 'none'.