CVE-2024-34145

What it actually does

This is a privilege-dependent remote code execution vulnerability in Jenkins Script Security Plugin. In affected versions (1335.vf07d9ce377a_e and earlier), a user who is allowed to define and run sandboxed scripts, such as Pipeline Groovy code, can create sandbox-defined classes that shadow certain non-sandbox classes and bypass Script Security sandbox enforcement. Once the sandbox is bypassed, the script can invoke otherwise-blocked Java/Groovy APIs and execute arbitrary code inside the Jenkins controller JVM, with the privileges of the Jenkins controller process.

Why it matters to the business

Successful exploitation can give a low-privileged Jenkins user or anyone able to influence trusted Pipeline code control over the Jenkins controller. That can lead to theft of build secrets, credentials, signing keys, source code, deployment tokens, and cloud access keys; tampering with build artifacts; disruption of CI/CD operations; and potential compromise of downstream production environments. Although this is not currently listed in CISA KEV and the provided EPSS is low, the impact is high because Jenkins controllers commonly hold sensitive credentials and have broad deployment reach.

How an attack unfolds

An attacker first obtains or abuses an account, repository role, or job permission that allows them to define and execute sandboxed Jenkins scripts, commonly through Pipeline jobs, shared libraries, or SCM-controlled Jenkinsfiles. They then submit crafted Groovy code that defines classes inside the sandbox whose names or structure shadow specific classes that exist outside the sandbox. Due to the sandbox bypass flaw, Script Security fails to enforce the expected restrictions for that code path. The attacker uses the bypass to call dangerous Java or Groovy functionality that would normally require script approval, such as process execution, file access, reflection, network connections, or credential access. The malicious script then runs in the Jenkins controller JVM, allowing command execution as the Jenkins service account, reading Jenkins secrets, modifying jobs or plugins, staging persistence, or pivoting to connected build agents and deployment targets.

How to fix it

Upgrade Jenkins Script Security Plugin to a fixed release newer than 1335.vf07d9ce377a_e, preferably the latest version available from the Jenkins update center. If an exact fixed version is required for change control, use the fixed version listed in the Jenkins security advisory for CVE-2024-34145 or a later release. Restart Jenkins if required for plugin replacement to take effect. As compensating controls until upgrade is complete, restrict who can configure jobs, create Pipelines, modify Jenkinsfiles, manage shared libraries, or otherwise run sandboxed scripts; require code review for Pipeline changes; limit SCM write access to repositories that feed Jenkins jobs; and avoid granting broad Job/Configure, Job/Create, Overall/RunScripts, or administrative permissions to untrusted users. Review and minimize stored credentials available to affected jobs.

How to confirm the fix worked

Confirm the installed Script Security Plugin version is later than 1335.vf07d9ce377a_e using the Jenkins plugin manager, the Jenkins CLI, or the plugin manifest under the Jenkins home plugins directory. Verify that Jenkins has been restarted or that the updated plugin is actively loaded. Review role-based access controls to confirm only trusted users can define or modify Pipeline scripts, shared libraries, and Jenkinsfiles. Where safe and authorized, run a controlled regression test using known sandbox-restricted operations and verify they remain blocked unless explicitly approved. Check that script approvals have not unexpectedly expanded and that recent Pipeline changes were reviewed after the upgrade.

Typical attack path

1. Gain access to Jenkins with permission to create, modify, or trigger a Pipeline or other sandboxed script execution path.
2. Identify a job, shared library, or SCM-controlled Jenkinsfile where sandboxed Groovy code will be executed by the Jenkins controller.
3. Insert crafted Groovy code that defines sandbox-local classes designed to shadow vulnerable non-sandbox classes.
4. Trigger the build or script execution path.
5. Abuse the sandbox bypass to call restricted Java/Groovy APIs that would normally be blocked or require administrator approval.
6. Execute commands, read files, access Jenkins credentials, or modify controller-side configuration in the context of the Jenkins controller JVM.
7. Use stolen credentials or CI/CD trust relationships to pivot into source code repositories, artifact registries, cloud environments, or deployment targets.

How to detect it

There is no single reliable, vulnerability-specific indicator that proves exploitation. Hunt for suspicious activity from the Jenkins controller around the time untrusted or recently modified Pipeline scripts ran. Review Jenkins controller logs, build console output, job configuration history, SCM commit history for Jenkinsfiles and shared libraries, script approval records, audit logs, plugin manager history, and operating system telemetry from the Jenkins controller host. Look for Pipeline Groovy that defines unusual classes, uses class shadowing patterns, invokes reflection, loads classes dynamically, accesses Jenkins internals, reads credential stores, opens outbound network connections, or attempts process execution. Correlate builds initiated by low-privileged users with unexpected child processes spawned by the Jenkins controller JVM, suspicious file reads under the Jenkins home directory, changes to jobs or credentials, new admin users or API tokens, modified init scripts, newly installed plugins, or unexplained outbound connections. If EDR data is available, search for shell, PowerShell, curl, wget, Python, Perl, bash, sh, cmd.exe, or other utilities spawned by the Jenkins Java process.

• Script Security Plugin 1335.vf07d9ce377a_e
• script-security.jpi
• script-security.hpi
• org.jenkinsci.plugins.scriptsecurity.sandbox
• org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException
• Scripts not permitted to use
• java.lang.Runtime.getRuntime
• Runtime.getRuntime().exec
• new ProcessBuilder
• java.lang.ProcessBuilder
• GroovyShell
• GroovyClassLoader
• Class.forName
• getDeclaredMethod
• setAccessible(true)
• Jenkins.instance
• Jenkins.get()
• com.cloudbees.plugins.credentials.CredentialsProvider
• /var/lib/jenkins/scriptApproval.xml
• /var/lib/jenkins/secrets/master.key
• /var/lib/jenkins/secrets/hudson.util.Secret
• $JENKINS_HOME/scriptApproval.xml
• $JENKINS_HOME/secrets/master.key
• $JENKINS_HOME/secrets/hudson.util.Secret

What your security team should do

• Prioritize upgrading Jenkins Script Security Plugin across all Jenkins controllers to a fixed or latest available release.
• Inventory Jenkins controllers and identify any running Script Security Plugin version 1335.vf07d9ce377a_e or earlier.
• Audit users, groups, service accounts, and SCM integrations that can create or modify Pipeline jobs, Jenkinsfiles, shared libraries, or sandboxed scripts.
• Review recent Pipeline, Jenkinsfile, and shared library changes for unusual Groovy constructs, class definitions, reflection, process execution, file reads, network calls, or credential access.
• Rotate high-value Jenkins credentials if there is evidence that untrusted sandboxed scripts ran on an affected controller.
• Harden CI/CD permissions so untrusted contributors cannot cause controller-side Groovy execution without review.
• Enable or centralize Jenkins audit logs, build logs, controller logs, SCM webhook logs, and operating system process telemetry for investigation and future detection.