GHSA-4mpj-488r-vh6m — apoc
CRITICALGHSA-4mpj-488r-vh6m is a critical-severity (CVSS 9.1) Path Traversal vulnerability in org.neo4j.procedure:apoc. A fix is available for org.neo4j.procedure:apoc — see the affected versions and patch details below.
Neo4j Graph Database vulnerable to Path Traversal
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-4mpj-488r-vh6m by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
org.neo4j.procedure:apoc☕org.neo4j.procedure:apoc☕org.neo4j.procedure:apoc☕org.neo4j.procedure:apocReal-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
Directory Traversal Vulnerabilities found in several functions of apoc plugins in Neo4j Graph database. The attacker can retrieve and download files from outside the configured directory on the affected server. Under some circumstances, the attacker can also create files.
Patches
The users should aim to use the latest released version compatible with their Neo4j version. The minimum versions containing patch for this vulnerability (for Neo4j 4.2, 4.3, and 4.4 bundled with APOC, upgrade to the appropriate patched version): 3.5 - bundle n/a, standalone 3.5.0.17 4.2 - bundle 4.2.13, standalone 4.2.0.10 4.3 - bundle 4.3.9, standalone 4.3.0.4 4.4 - bundle 4.4.2, standalone 4.4.0.1
Workarounds
If you cannot upgrade the library, you can control the allowlist of the functions that can be used in your system:
For more information
If you have any questions or comments about this advisory:
- Open an issue in neo4j-apoc-procedures
- Email us at [email protected]
Credits
We want to publicly recognize the contribution of Nicolai Grødum from the Red Team of PwC Norway for reporting this issue and following the responsible disclosure policy.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.neo4j.procedure:apoc | all versions | 3.5.17org.neo4j.procedure:apoc:3.5.17 |
| ☕Maven | org.neo4j.procedure:apoc | ≥ 4.2.0&&< 4.2.10 | 4.2.10org.neo4j.procedure:apoc:4.2.10 |
| ☕Maven | org.neo4j.procedure:apoc | ≥ 4.3.0.0&&< 4.3.0.4 | 4.3.0.4org.neo4j.procedure:apoc:4.3.0.4 |
| ☕Maven | org.neo4j.procedure:apoc | ≥ 4.4.0.0&&< 4.4.0.1 | 4.4.0.1org.neo4j.procedure:apoc:4.4.0.1 |
Affected Products
awesome proceduresneo4jDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.neo4j.procedure:apoc, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.neo4j.procedure:apoc to 3.5.17 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4mpj-488r-vh6m 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-4mpj-488r-vh6m in your dependencies?
Find it across Maven, including transitive dependencies.