Jenkins is a widely used automation server for building, deploying, and automating software projects. Historically, its security model has been improved over multiple updates due to its popularity and wide adoption. One of the critical protections Jenkins employs is the Script Security Plugin, designed to restrict and approve the execution of Groovy scripts. However, a security vulnerability tracked as CVE-2022-45379 was discovered in the way script approvals were handled — specifically in Jenkins Script Security Plugin versions 1189.vb_a_b_7c8fd5fde and earlier.

In this post, we’ll walk you through the issue, demonstrate potential exploit scenarios, and provide resources for further study.

What’s the Vulnerability?

The crux of CVE-2022-45379 lies in how Jenkins stored approvals for "whole-script" scripts. When a script was marked as “approved," the plugin stored only its SHA-1 hash in the approvals list. Future attempts to run scripts would be compared by calculating the SHA-1 hash of the script’s content.

Why is that a problem?

SHA-1 is an outdated cryptographic hash function that has known collision vulnerabilities. This means two *different* scripts can have the *same* SHA-1 hash — a possibility discovered in practice since at least 2017 (Shattered Attack). If an attacker can produce a malicious script that matches the SHA-1 hash of a previously approved benign script, Jenkins would allow the execution of *that malicious script*, believing it was trusted.

Understanding the Impact

Who’s Affected?  
Any Jenkins instance using Script Security Plugin version 1189.vb_a_b_7c8fd5fde or older that uses whole-script approval (as opposed to signature-based approvals).

What Could Go Wrong?  
Loss of trust in script approvals: Any previously approved script could be used as a stepping stone for malicious code execution, breaking core Jenkins security guarantees.

What’s the Exploitability?  
SHA-1 collisions for arbitrary payloads are non-trivial, but *practical* collision attacks (like SHAttered) have proven real-world feasibility — especially if an attacker can submit approval requests and observe hash values.

Step-by-Step Exploit Example

While performing a real SHA-1 collision attack (like crafting a matched malicious script) requires significant resources and cryptographic knowledge, here is a simplified example to illustrate the surface:

1. Victim Approves an Innocuous Script

// hello.groovy
println "Hello, Jenkins!"

This script is submitted for approval and its SHA-1 hash is stored

# Calculate SHA-1 hash
sha1sum hello.groovy
# Output: e505818d7d4ff59b7c79d912fb717996b09fed90  hello.groovy

2. Attacker Produces Colliding Malicious Script

Suppose the attacker generates a *different* script that produces the same SHA-1 hash, potentially using advanced tools (HashClash) or new methods. Their “evil.groovy” could be:

// evil.groovy
// crafted padding and junk to collide SHA-1
"rm -rf /".execute()

The SHA-1 hash is artificially constructed to match e505818d7d4ff59b7c79d912fb717996b09fed90.

3. Attacker Submits Malicious Script

Now the attacker submits "evil.groovy" for execution. Jenkins checks the SHA-1 hash, finds it *matches* the previously approved innocent script, and allows execution, thus running the attacker’s code.

*In reality, crafting arbitrary script collisions with desired content is still computationally expensive — but proven possible. The design flaw is the weak hash reliance, not strict theoretical exploitability.*

Code Internals: Where Does This Happen?

Script approvals are stored in the scriptApproval.xml file in Jenkins home. Each "approved script" appears as a SHA-1 value:

<approvedScriptHashes>
  <string>e505818d7d4ff59b7c79d912fb717996b09fed90</string>
</approvedScriptHashes>

The relevant code in Jenkins Script Security Plugin (pre-fix)

String scriptHash = Util.getDigestOf(script); // Uses SHA-1
if (approvedScriptHashes.contains(scriptHash)) {
    // script is allowed
}

Remediation

Fix:

Improved approval storage and validation.

How to fix your instance:

Jenkins Security Advisory:

CVE-2022-45379 Full Report

GitHub plugin repo:

jenkinsci/script-security-plugin

SHA-1 collision details:

SHAttered

HashClash attack toolkit:

GitHub: hashclash

Takeaways

- Never rely on cryptographically broken algorithms for security-critical functions. SHA-1 is no longer safe for *any* approval or identity checking.

Review script approval policies and audit past approvals wherever possible.

Jenkins administrators should act fast and review their script security stance to ensure this — or similar — issues don’t put their automation or supply chains at risk.


*For any comments or additional questions, refer to the official Jenkins Security Advisory or get in touch with Jenkins security mailing list.*

Timeline

Published on: 11/15/2022 20:15:00 UTC
Last modified on: 11/18/2022 20:26:00 UTC