Jenkins Script Security EUVD-2026-80748

Exploitation requires an account with Jenkins permission to define and run sandboxed scripts - specifically Groovy scripts or Pipeline definitions that are executed through the Script Security sandbox (typically Job/Configure or equivalent Pipeline-authoring rights). This is the primary limiting factor (reflected as PR:L): an anonymous or read-only user cannot trigger it. No special non-default configuration is needed beyond the sandbox being in use (the sandbox is the default protection for untrusted Pipelines), and no user interaction or additional victim action is required once the malicious script runs. The affected component is Jenkins Script Security Plugin at version 1415.v9a_f9b_3a_c253d and earlier; the flaw is in how the cast on a collection object is checked, so it applies to default sandbox behavior across such installations.

This is a genuine high-priority issue for any organization running multi-tenant Jenkins, though not an emergency drop-everything scenario. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) is credible: network-reachable, low complexity, and full triad impact because sandbox escape yields arbitrary code execution in the Jenkins controller JVM - CISA SSVC rates Technical Impact as 'total', consistent with controller-level RCE. The tempering signals are important and coherent with each other: PR:L reflects that the attacker must already hold permission to define and run sandboxed scripts/Pipelines, SSVC Automatable is 'no', and SSVC Exploitation is 'none' (no active exploitation observed). There is no CISA KEV listing, no public exploit code, and no EPSS score provided, so no evidence of opportunistic mass exploitation exists at time of analysis. The realistic threat model is a low-privileged but trusted insider (or a compromised developer account) escalating from constrained script authoring to full controller compromise - a well-known and serious Jenkins escalation class. No signals conflict: every source points to 'high technical impact, gated by authoring privilege, no in-the-wild activity yet.'

An attacker holding Jenkins permission to author and run sandboxed Groovy scripts or Pipeline definitions writes a script that casts a collection to another type; because Script Security validates only the operations Groovy performs on the collection's elements and not the cast performed on the collection object itself, the sandbox check is bypassed. The script then executes arbitrary Groovy/Java in the controller JVM, giving the attacker code execution with the controller's privileges (credentials, secrets, agent control). No public proof-of-concept was identified at time of analysis, though the vendor advisory describes the mechanism precisely.