Jenkins Script Security CVE-2026-92127

Two conditions must combine: (1) the attacker must be able to define script-security classpath entries in an item/job configuration, i.e. hold job-configure access on a controller running Script Security Plugin 1415.v9a_f9b_3a_c253d or earlier; and (2) a user with Overall/Administer permission must then either copy that item or update its configuration through the REST API or CLI, which is the specific action that auto-approves the classpath without manual review. Exploitation is LIMITED by this required privileged interaction (UI:R) and by the attacker needing pre-existing config-edit privileges (PR:L) - it is not a single-actor unauthenticated exploit; installations where only administrators can author jobs, or where admins do not copy jobs / drive config via REST/CLI, are effectively not exposed.

This is a genuine remote-code-execution flaw (CWE-94) in a near-ubiquitous Jenkins plugin, but its practical risk is gated by a confused-deputy precondition rather than the raw 8.0 CVSS score implying. The vendor vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H is internally consistent with the description: PR:L reflects that the attacker must already have enough access to define classpath entries in an item configuration, and UI:R reflects that a separate privileged user with Overall/Administer must perform the triggering action (copying the item, or updating its config via the REST API or CLI), which is what auto-approves the malicious classpath. No EPSS score, no SSVC decision data, and no KEV or POC signal are present in the input, so per precision rules this is 'no public exploit identified at time of analysis' - not active exploitation. The realistic priority is high for organizations running multi-user Jenkins controllers where lower-privileged users can edit job configs and admins routinely copy jobs or drive config changes over API/CLI, but it is materially lower where only administrators can define jobs. No signals conflict; the main limitation is the two-actor dependency, not any data contradiction.

A lower-privileged Jenkins user who can edit a job configuration inserts a malicious script-security classpath entry pointing at attacker-controlled JAR/Groovy code, which normally would require explicit administrator approval. An administrator later copies that job, or pushes its configuration through the REST API or CLI, and the plugin silently auto-approves the classpath - causing the attacker's code to execute in the Jenkins controller JVM. No public proof-of-concept is identified in the provided data.