sbt vulnerable to arbitrary file write via archive extraction (Zip Slip)GHSA-h9mw-grgx-2fhf
LOWFix: sbt/io#360GHSA-h9mw-grgx-2fhf is a low-severity (CVSS 3.9) Path Traversal vulnerability in org.scala-sbt:sbt. 1 public exploit or proof-of-concept reference is indexed, so weaponization risk is real. A fix is available for org.scala-sbt:sbt — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-h9mw-grgx-2fhf.
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
org.scala-sbt:sbt☕org.scala-sbt:io_2.12☕org.scala-sbt:io_2.13☕org.scala-sbt:io_3Real-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
Impact
Given specially crafted zip or JAR file, IO.unzip allows writing of arbitrary file. The follow is an example of a malicious entry:
+2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys
This would have a potential to overwrite /root/.ssh/authorized_keys. Within sbt's main code, IO.unzip is used in pullRemoteCache task and Resolvers.remote; however many projects use IO.unzip(...) directly to implement custom tasks - https://github.com/search?q=IO.unzip+language%3AScala&type=code&l=Scala&p=1
Patches
The problem has been patched in https://github.com/sbt/io/pull/360 sbt 1.9.7 is available with the fix.
Workarounds
A workaround might be use some other library to unzip.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.scala-sbt:sbt | ≥ 0.3.4&&< 1.9.7 | 1.9.7org.scala-sbt:sbt:1.9.7 |
| ☕Maven | org.scala-sbt:io_2.12 | ≥ 1.0.0&&< 1.9.7 | 1.9.7org.scala-sbt:io_2.12:1.9.7 |
| ☕Maven | org.scala-sbt:io_2.13 | ≥ 1.0.0&&< 1.9.7 | 1.9.7org.scala-sbt:io_2.13:1.9.7 |
| ☕Maven | org.scala-sbt:io_3 | ≥ 1.0.0&&< 1.9.7 | 1.9.7org.scala-sbt:io_3:1.9.7 |
Affected Products
ioscala-sbtsbtscala-sbtResearch use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.scala-sbt:sbt, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.scala-sbt:sbt to 1.9.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h9mw-grgx-2fhf 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-h9mw-grgx-2fhf in your dependencies?
Find it across Maven, including transitive dependencies.