GHSA-c43q-5hpj-4crv
MEDIUMLocal information disclosure via system temporary directory
Blast Radius
org.glassfish.jersey.core:jersey-common☕org.glassfish.jersey.core:jersey-commonReal-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
Eclipse Jersey 2.28 - 2.33 and Eclipse Jersey 3.0.0 - 3.0.1 contains a local information disclosure vulnerability. This is due to the use of the File.createTempFile which creates a file inside of the system temporary directory with the permissions: -rw-r--r--. Thus the contents of this file are viewable by all other users locally on the system. As such, if the contents written is security sensitive, it can be disclosed to other local users.
Workaround
This issue can be mitigated by manually setting the java.io.tmpdir system property when launching the JVM.
Patches
Jersey 2.34 and 3.0.2 forward sets the correct permissions on the temporary file created by Jersey.
References
- https://github.com/eclipse-ee4j/jersey/pull/4712
- CWE-378: Creation of Temporary File With Insecure Permissions
- CWE-379: Creation of Temporary File in Directory with Insecure Permissions
Similar Vulnerabilities
Similar, but not the same:
- JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp
- Google Guava - https://github.com/google/guava/issues/4011
- Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945
- JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
- Eclipse Jetty - https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6
Original Disclosure:
Hello Jersey Security Team,
Utilizing a custom CodeQL query written as a part of the GitHub Security Lab Bug Bounty program, I've unearthed a local temporary file information disclosure vulnerability.
You can see the custom CodeQL query utilized here: https://lgtm.com/query/8831016213790320486/
This particular vulnerability exists because on unix-like systems (not including modern versions of MacOS) the system temporary directory is shared between all users. As such, failure to correctly set file permissions and/or verify exclusive creation of directories can lead to either local information disclosure, or local file hijacking by another user.
This vulnerability impacts the following locations in this project's source:
- https://github.com/eclipse-ee4j/jersey/blob/01c6a32a2064aeff2caa8133472e33affeb8a29a/core-common/src/main/java/org/glassfish/jersey/message/internal/FileProvider.java#L64-L73
- https://github.com/eclipse-ee4j/jersey/blob/01c6a32a2064aeff2caa8133472e33affeb8a29a/media/multipart/src/main/java/org/glassfish/jersey/media/multipart/internal/FormDataParamValueParamProvider.java#L202-L208
This vulnerability exists because of the vulnerability in the
Utils.createTempFile:This is because
File.createTempFilecreates a file inside of the system temporary directory with the permissions:-rw-r--r--. Thus the contents of this file are viewable by all other users locally on the system.If there is sensitive information written to these files, it is disclosed to other local users on this system.
The fix for this vulnerability is to use the
FilesAPI (instead of theFileAPI) to create temporary files/directories as this new API correctly sets the posix file permissions.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.glassfish.jersey.core:jersey-common | ≥ 2.28&&< 2.34 | 2.34 |
| ☕Maven | org.glassfish.jersey.core:jersey-common | ≥ 3.0.0&&< 3.0.2 | 3.0.2 |
Research 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.glassfish.jersey.core:jersey-common. 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 org.glassfish.jersey.core:jersey-common to 2.34 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c43q-5hpj-4crv 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-c43q-5hpj-4crv 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-c43q-5hpj-4crv. 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-c43q-5hpj-4crv in your dependencies?
O3 detects GHSA-c43q-5hpj-4crv across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.