CVE-2025-52999: jackson-core vulnerability in transitive dependency
Security Vulnerability
shadow-cljs has a HIGH severity vulnerability through a transitive dependency.
CVE Details
- CVE ID: CVE-2025-52999
- Severity: HIGH (CVSS 8.7)
- Component: jackson-core < 2.15.0
- Impact: StackOverflowError with deeply nested JSON (Denial of Service)
Vulnerability Source
shadow-cljs → s3-wagon-private 1.3.5 → jackson-core 2.12.4 (VULNERABLE)
shadow-cljs-jar → s3-wagon-private 1.3.5 → jackson-core 2.12.4 (VULNERABLE)
Both the main project and packages/shadow-cljs-jar are affected.
Why This Can't Be Fixed By Simple Upgrade
s3-wagon-privatelatest version is 1.3.5 (released Nov 2021)- No newer version available that includes the patched jackson-core 2.15.0+
- The library appears to be unmaintained (?} (no recent activity)
Proposed Solution
Use Leiningen's :managed-dependencies to override jackson-core to version 2.15.0 (patched) in both:
- Main
project.clj packages/shadow-cljs-jar/project.clj
The direct dependency cannot be upgraded so this seemed like an "ok" solution.
Verification
- All 42 tests pass with the fix
- Trivy security scan confirms 0 vulnerabilities after fix
lein deps :treeconfirms jackson-core 2.15.0 is used
References
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-52999
- GitHub Advisory: https://github.com/FasterXML/jackson-core/security/advisories/GHSA-h46c-h94j-95f3
- Similar fix pattern: #1082 (previous jackson CVE fix)
I have a fix ready if you want it.
I can upload local trivy scan results if you want that as well.
I pretty much consider this irrelevant given the context this is used in. The maven s3 extension is used to gain access to private maven repos hosted on s3. Given they are private they are most likely your own. So, in theory you can DoS yourself only. Definitely not HIGH severity.
Thanks for the response @thheller - I'll float this by our corp AppSec division as well as our team to see what our next steps will be.
Note that you can just add the "fixed" dependency to your own dependencies. This will just override whatever shadow-cljs might bring in by default. There is no need to do this at the shadow-cljs level.
And if you are not using that feature anyway you could possibly just use :exclusions to get rid of it entirely.