GHSA-9654-pr4f-gh6m
HIGHHL7 FHIR Partial Path Zip Slip due to bypass of CVE-2023-24057
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
ca.uhn.hapi.fhir:org.hl7.fhir.core☕ca.uhn.hapi.fhir:org.hl7.fhir.convertors☕ca.uhn.hapi.fhir:org.hl7.fhir.r4b☕ca.uhn.hapi.fhir:org.hl7.fhir.r5☕ca.uhn.hapi.fhir:org.hl7.fhir.utilities☕ca.uhn.hapi.fhir:org.hl7.fhir.validationReal-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
Zip Slip protections implemented in CVE-2023-24057 (GHSA-jqh6-9574-5x22) can be bypassed due a partial path traversal vulnerability.
This issue allows a malicious actor to potentially break out of the TerminologyCacheManager cache directory. The impact is limited to sibling directories.
To demonstrate the vulnerability, consider userControlled.getCanonicalPath().startsWith("/usr/out") will allow an attacker to access a directory with a name like /usr/outnot.
Why?
To demonstrate this vulnerability, consider "/usr/outnot".startsWith("/usr/out").
The check is bypassed although /outnot is not under the /out directory.
It's important to understand that the terminating slash may be removed when using various String representations of the File object.
For example, on Linux, println(new File("/var")) will print /var, but println(new File("/var", "/") will print /var/;
however, println(new File("/var", "/").getCanonicalPath()) will print /var.
The Fix
Comparing paths with the java.nio.files.Path#startsWith will adequately protect againts this vulnerability.
For example: file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY) or file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY_FILE.getCanonicalFile().toPath())
Other Examples
- CVE-2022-31159 - aws/aws-sdk-java
- CVE-2022-23457 - ESAPI/esapi-java-legacy
Vulnerability
While getAbsolutePath will return a normalized path, because the string path is not slash terminated, the guard can be bypassed to write the contents of the Zip file to a sibling directory of the cache directory.
Patches
All org.hl7.fhir.core libraries should be updated to 5.6.106.
Workarounds
Unknown
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | ca.uhn.hapi.fhir:org.hl7.fhir.core | all versions | 5.6.106 |
| ☕Maven | ca.uhn.hapi.fhir:org.hl7.fhir.convertors | all versions | 5.6.106 |
| ☕Maven | ca.uhn.hapi.fhir:org.hl7.fhir.r4b | all versions | 5.6.106 |
| ☕Maven | ca.uhn.hapi.fhir:org.hl7.fhir.r5 | all versions | 5.6.106 |
| ☕Maven | ca.uhn.hapi.fhir:org.hl7.fhir.utilities | all versions | 5.6.106 |
| ☕Maven | ca.uhn.hapi.fhir:org.hl7.fhir.validation | all versions | 5.6.106 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ca.uhn.hapi.fhir:org.hl7.fhir.core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update ca.uhn.hapi.fhir:org.hl7.fhir.core to 5.6.106 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9654-pr4f-gh6m is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-9654-pr4f-gh6m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-9654-pr4f-gh6m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9654-pr4f-gh6m in your dependencies?
O3 detects GHSA-9654-pr4f-gh6m across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.