Jenkins Script Security CVE-2026-92126

Requires an authenticated Jenkins user holding permission to define and run sandboxed scripts, including Pipelines (PR:L) - this is not remote-unauthenticated. Exploitation further depends on a 'suitable class' being present on the classpath of the component that evaluates the script, so the presence of a usable gadget class is an environmental precondition (reflected as AC:H). The core limiting factor is that only instances where untrusted or low-privilege users can author sandboxed scripts are meaningfully exposed; single-administrator instances where all script authors already have full control gain little for an attacker. Affected: Script Security Plugin 1415.v9a_f9b_3a_c253d and all earlier versions.

This is a genuine, high-priority sandbox escape in Jenkins' security-critical Script Security Plugin, but the risk is scoped by real preconditions rather than being a mass-exploitable internet threat. The vendor CVSS of 8.5 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) is internally consistent with the description: it is network-reachable, requires an authenticated user with permission to define and run sandboxed scripts/Pipelines (PR:L), carries an environmental AC:H because a 'suitable class' must be present on the evaluating component's classpath, and scores S:C/C:H/I:H/A:H because breaking out of the Groovy sandbox yields full code execution on the Jenkins controller - crossing the security boundary the sandbox is designed to enforce. Exploitation signals are cool: EPSS is only 0.20% (11th percentile), the CVE is not in CISA KEV, and no public exploit is identified in the provided sources - so there is no evidence of active exploitation or weaponization at time of analysis. The tension to weigh is that Script Security sandbox bypasses are historically a heavily-researched class (numerous prior Jenkins SECURITY advisories), so despite the low EPSS this deserves prompt patching in any multi-tenant Jenkins where untrusted users can author Pipelines. In single-admin Jenkins instances where every script author already has full admin, the practical severity is much lower.

A low-privileged Jenkins user who is permitted to author and run a sandboxed Pipeline submits a Groovy script containing a @Builder annotation whose builderStrategy member references an attacker-chosen class already on the controller's classpath. When the plugin evaluates the script it fails to reject the annotation, instantiating/invoking that class outside the sandbox and achieving code execution on the Jenkins controller. No public exploit code is identified at time of analysis, and the AC:H reflects that a suitable gadget class must exist on the classpath.