CVE-2022-36007 is a medium-severity (CVSS 6.1) Path Traversal vulnerability in com.github.jlangch:venice. 1 public exploit or proof-of-concept reference is indexed, so weaponization risk is real. A fix is available for com.github.jlangch:venice — see the affected versions and patch details below.
Partial Path Traversal in com.github.jlangch:venice
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 CVE-2022-36007.
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.github.jlangch:veniceReal-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
A partial path traversal issue exists within the functions load-file and load-resource. These functions can be limited to load files from a list of load paths.
Assuming Venice has been configured with the load paths: [ "/Users/foo/resources" ]
When passing relative paths to these two vulnerable functions everything is fine:
(load-resource "test.png") => loads the file "/Users/foo/resources/test.png"
(load-resource "../resources-alt/test.png") => rejected, outside the load path
When passing absolute paths to these two vulnerable functions Venice may return files outside the configured load paths:
(load-resource "/Users/foo/resources/test.png") => loads the file "/Users/foo/resources/test.png"
(load-resource "/Users/foo/resources-alt/test.png") => loads the file "/Users/foo/resources-alt/test.png" !!!
The latter call suffers from the Partial Path Traversal vulnerability.
This issue’s scope is limited to absolute paths whose name prefix matches a load path. E.g. for a load-path "/Users/foo/resources", the actor can cause loading a resource also from "/Users/foo/resources-alt", but not from "/Users/foo/images".
Versions of Venice before and including v1.10.16 are affected by this issue.
Patches
Upgrade to Venice >= 1.10.17, if you are on a version < 1.10.17
Workarounds
If you cannot upgrade the library, you can control the functions that can be used in Venice with a sandbox. If it is appropriate, the functions load-file and load-resource can be blacklisted in the sandbox.
References
For more information
If you have any questions or comments about this advisory:
- Open an issue in GitHub Venice
- Email us at juerg.ch
Credits
I want to publicly recognize the contribution of Jonathan Leitschuh for reporting this issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | com.github.jlangch:venice | all versions | 1.10.17com.github.jlangch:venice:1.10.17 |
Affected Products
venicevenice_projectResearch 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 com.github.jlangch:venice, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update com.github.jlangch:venice to 1.10.17 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2022-36007 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 CVE-2022-36007 in your dependencies?
Find it across Maven, including transitive dependencies.