CVE-2024-34144

What it actually does

The vulnerability is a sandbox bypass in Jenkins Script Security Plugin 1335.vf07d9ce377a_e and earlier involving crafted Groovy constructor bodies. A user who can define and run sandboxed scripts, such as Pipeline scripts or other Jenkins Groovy execution points, can escape the intended Script Security restrictions and execute arbitrary code inside the Jenkins controller JVM. Because code runs in the controller process, successful exploitation can allow access to Jenkins secrets, credentials, job configurations, workspace metadata, plugin APIs, controller filesystem resources, and potentially command execution on the underlying controller host depending on JVM and operating-system permissions. The supplied affected-product metadata also references glpi-project/glpi with a fixed Git commit, which should be validated against vendor advisories because it conflicts with the Jenkins-focused vulnerability description.

Why it matters to the business

Compromise of the Jenkins controller can affect software delivery, secrets management, and production deployment integrity. An attacker could steal deployment credentials, alter build pipelines, tamper with released artifacts, implant malicious code into CI/CD workflows, or disrupt build and release operations. Although the issue is not listed in CISA KEV and no exploit maturity is supplied, the CVSS score is critical and the EPSS value is elevated, so internet-exposed or broadly delegated CI/CD systems should be treated as high priority. The vulnerability has been public for a long period, increasing the likelihood that attackers and researchers understand the vulnerable code paths.

How an attack unfolds

An attacker first obtains or abuses access to a feature that allows execution of sandboxed Jenkins Groovy, such as a Pipeline definition, multibranch project configuration, shared library path, or another plugin feature that delegates to the Script Security sandbox. The attacker submits a specially crafted script using constructor-body behavior that is not correctly constrained by the affected sandbox implementation. When Jenkins evaluates the script, the sandbox fails to enforce the expected method, constructor, or object access restrictions, allowing the script to invoke privileged Java or Jenkins APIs from inside the controller JVM. From there, the attacker can enumerate Jenkins internals, read credentials, access files under the Jenkins home directory, modify jobs or build steps, create persistence through jobs or init hooks if filesystem access is possible, and potentially launch operating-system commands from the controller process. In environments where Jenkins can deploy to production or sign artifacts, the attacker can pivot from controller compromise to software supply-chain compromise.

How to fix it

Upgrade Jenkins Script Security Plugin to a version newer than 1335.vf07d9ce377a_e that contains the vendor fix, and align Jenkins core and dependent Pipeline plugins with the vendor-supported compatibility matrix. Review Jenkins security advisories for the exact fixed plugin release applicable to the deployed Jenkins line. If the supplied package metadata is applicable to a GLPI source deployment, update glpi-project/glpi to commit e2d0f893191952f35c6b1a6013418308e3e1dbc2 or a release that includes it; however, validate this separately because the affected-product metadata conflicts with the Jenkins vulnerability description. Until patching is complete, restrict who can create or modify Pipeline jobs, Jenkinsfiles, shared libraries, and any feature that runs sandboxed Groovy; disable untrusted pull request builds where they can execute Jenkinsfiles; require administrative review for new script-capable jobs; isolate Jenkins controllers from the internet; rotate credentials potentially accessible to Jenkins after remediation if exploitation is suspected; and review controller filesystem permissions to limit the blast radius of JVM-level code execution.

How to confirm the fix worked

Confirm the installed Script Security Plugin version from the Jenkins plugin manager, the plugin directory manifest, or Jenkins CLI, and verify it is newer than 1335.vf07d9ce377a_e or matches the fixed release identified by the Jenkins advisory. Validate that Pipeline and Groovy-related plugins remain compatible after upgrade and that Jenkins has been restarted if required for plugin replacement. Test that untrusted sandboxed scripts are still blocked from invoking restricted Java and Jenkins APIs, and verify that unauthorized users cannot create or modify script-capable jobs. For Git-based GLPI tracking, confirm the deployed source tree contains commit e2d0f893191952f35c6b1a6013418308e3e1dbc2 if that product metadata is relevant. Run configuration audits to ensure only trusted groups have Job/Configure, Job/Build, Overall/RunScripts, SCM write, and shared-library administration privileges.

Typical attack path

1. Identify a Jenkins instance running Script Security Plugin 1335.vf07d9ce377a_e or earlier, or otherwise confirm the vulnerable sandbox implementation is present.
2. Obtain permission to define or influence sandboxed Groovy execution, such as Pipeline job creation, Jenkinsfile modification, pull request build influence, shared library contribution, or another scriptable Jenkins feature.
3. Create a crafted Groovy script using constructor-body behavior that triggers the sandbox bypass.
4. Run the Pipeline or script so Jenkins evaluates it on the controller JVM under the vulnerable Script Security Plugin.
5. Use the sandbox escape to call normally restricted Java or Jenkins APIs.
6. Read Jenkins secrets, credentials, job definitions, build logs, and configuration files, or alter CI/CD jobs and plugins.
7. Optionally execute operating-system commands, create persistent jobs or scripts, tamper with build artifacts, or pivot using credentials recovered from Jenkins.

How to detect it

Investigate Jenkins controller logs, build logs, job configuration history, SCM history for Jenkinsfiles and shared libraries, plugin audit logs, reverse proxy logs, and operating-system telemetry from the Jenkins controller. Look for sandbox rejection messages shortly before successful builds by the same user, unusual constructor-heavy Groovy code, attempts to access Jenkins internals from sandboxed Pipeline scripts, references to credential APIs, filesystem paths under JENKINS_HOME, Java process execution APIs, encoded or obfuscated Groovy, unexpected outbound connections from the Jenkins controller, and new or modified jobs that persist suspicious build steps. Review changes to script approvals, job config.xml files, shared libraries, and global pipeline libraries. If endpoint telemetry is available, search for child processes spawned by the Jenkins Java process, such as shell, PowerShell, curl, wget, Python, Perl, or netcat. Because this is a sandbox bypass, exploitation may appear as an otherwise normal Pipeline build rather than a distinct web exploit, so correlate suspicious Pipeline content, job authorship, build timing, and controller-side process or file activity.

• org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException
• org.kohsuke.groovy.sandbox
• GroovySandbox
• Script Security Plugin
• scriptApproval.xml
• CpsFlowDefinition
• Jenkins.instance
• jenkins.model.Jenkins.instance
• hudson.model.Hudson.instance
• com.cloudbees.plugins.credentials.CredentialsProvider
• getCredentials
• getPlainText
• Secret.toString
• java.lang.Runtime.getRuntime().exec
• Runtime.getRuntime().exec
• java.lang.ProcessBuilder
• new ProcessBuilder
• /var/lib/jenkins/secrets/
• /var/jenkins_home/secrets/
• /var/lib/jenkins/credentials.xml
• /var/jenkins_home/credentials.xml
• $JENKINS_HOME/secrets/
• $JENKINS_HOME/credentials.xml
• sh -c
• bash -c
• powershell.exe
• cmd.exe /c
• curl http
• wget http
• nc -e
• ncat -e

What your security team should do

• Prioritize patching Jenkins Script Security Plugin on all controllers, especially those reachable by many developers, connected to production deployment credentials, or processing untrusted pull requests.
• Inventory all Jenkins instances and plugin versions; flag Script Security Plugin 1335.vf07d9ce377a_e and earlier as vulnerable.
• Temporarily restrict Pipeline creation, Jenkinsfile modification, shared library updates, and sandboxed Groovy execution to trusted maintainers until remediation is complete.
• Review recent Pipeline changes, shared library commits, job configuration changes, and builds submitted by newly added or lower-trust users.
• Hunt Jenkins logs and job histories for suspicious sandbox errors followed by successful builds, unusual Groovy constructs, credential access, filesystem reads, process execution, or outbound network activity from the controller.
• Rotate Jenkins-managed secrets, deployment tokens, signing keys, and SCM credentials if suspicious script execution is found.
• Disable or tightly gate builds from untrusted pull requests and external forks where Jenkins evaluates contributor-controlled Pipeline code.
• Harden Jenkins RBAC so users with job configuration rights are treated as high-trust CI/CD operators, not ordinary build users.
• Validate the conflicting product metadata against authoritative vendor advisories before applying GLPI-specific remediation actions.