Gradle Shadow: Zip Slip path traversal in ShadowCopyAction — no independent entry-name sanitizationGHSA-rr8v-fxxf-c986
HIGHFix: GradleUp/shadow@0c2744fGHSA-rr8v-fxxf-c986 is a high-severity (CVSS 8.1) Path Traversal vulnerability in com.gradleup.shadow:com.gradleup.shadow.gradle.plugin. A fix is available for com.gradleup.shadow:com.gradleup.shadow.gradle.plugin — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-rr8v-fxxf-c986.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
com.gradleup.shadow:com.gradleup.shadow.gradle.pluginReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
ShadowCopyAction in the Shadow plugin does not validate or sanitize ZIP entry names before writing them to the output fat JAR. A malicious upstream dependency containing path traversal sequences (e.g. ../../../../tmp/pwned.txt) in entry names will have those entries reproduced verbatim in the output shadow JAR.
Details
The vulnerability exists because Shadow relies entirely on Gradle's ZipFileTree for entry sanitization rather than implementing its own path validation. This means:
- Users on Gradle < 7.6.2 / 8.x < 8.2.0 are directly exploitable
- The produced shadow JAR becomes a Zip Slip weapon against any downstream consumer using unprotected extraction (raw ZipInputStream, older CI tooling, custom Java unpackers)
- If Shadow ever uses a non-ZipFileTree code path, protection disappears silently
Affected file: src/main/kotlin/com/github/jengelman/gradle/plugins/shadow/internal/ShadowCopyAction.kt
PoC
- Create a malicious JAR with path traversal entry:
import zipfile
with zipfile.ZipFile('evil.jar', 'w') as zf:
zf.writestr('../../../../tmp/zipslip_proof.txt', 'pwned')
- Add as dependency in a shadow project
- Run
gradle shadowJar - Run
unzip -l build/libs/*.jar | grep "\.\." - Traversal entry survives in output JAR
Impact
Any tool extracting the shadow JAR with unprotected extraction is subject to arbitrary file overwrite. Users on older Gradle versions are directly vulnerable at build time.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | com.gradleup.shadow:com.gradleup.shadow.gradle.plugin | all versions | 9.6.0com.gradleup.shadow:com.gradleup.shadow.gradle.plugin:9.6.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.gradleup.shadow:com.gradleup.shadow.gradle.plugin, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update com.gradleup.shadow:com.gradleup.shadow.gradle.plugin to 9.6.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rr8v-fxxf-c986 is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
Frequently Asked Questions
Is GHSA-rr8v-fxxf-c986 in your dependencies?
Find it across Maven, including transitive dependencies.