GHSA-269g-pwp5-87pp is a medium-severity (CVSS 4.4) Information Exposure vulnerability in junit:junit. 1 public exploit reference exists, so weaponization risk is real. O3 Security confirms whether GHSA-269g-pwp5-87pp is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
TemporaryFolder on unix-like systems does not limit access to created files
Real-World Exposure
junit:junitReal-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
Vulnerability
The JUnit4 test rule TemporaryFolder contains a local information disclosure vulnerability.
Example of vulnerable code:
public static class HasTempFolder {
@Rule
public TemporaryFolder folder = new TemporaryFolder();
@Test
public void testUsingTempFolder() throws IOException {
folder.getRoot(); // Previous file permissions: `drwxr-xr-x`; After fix:`drwx------`
File createdFile= folder.newFile("myfile.txt"); // unchanged/irrelevant file permissions
File createdFolder= folder.newFolder("subfolder"); // unchanged/irrelevant file permissions
// ...
}
}
Impact
On Unix like systems, the system's temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system.
This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability.
When analyzing the impact of this vulnerability, here are the important questions to ask:
- Do the JUnit tests write sensitive information, like API keys or passwords, into the temporary folder?
- If yes, this vulnerability impacts you, but only if you also answer 'yes' to question 2.
- If no, this vulnerability does not impact you.
- Do the JUnit tests ever execute in an environment where the OS has other untrusted users.
This may apply in CI/CD environments but normally won't be 'yes' for personal developer machines.
- If yes, and you answered 'yes' to question 1, this vulnerability impacts you.
- If no, this vulnerability does not impact you.
Patches
Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using.
- Java 1.7 and higher users: this vulnerability is fixed in 4.13.1.
- Java 1.6 and lower users: no patch is available, you must use the workaround below.
Workarounds
If you are unable to patch, or are stuck running on Java 1.6, specifying the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability.
References
- CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
- Fix commit https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae
Similar Vulnerabilities
- 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
For more information
If you have any questions or comments about this advisory, please pen an issue in junit-team/junit4.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | junit:junit | ≥ 4.7&&< 4.13.1 | 4.13.1 |
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 junit:junit. 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 junit:junit to 4.13.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-269g-pwp5-87pp 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-269g-pwp5-87pp 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-269g-pwp5-87pp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Frequently Asked Questions
Is GHSA-269g-pwp5-87pp in your dependencies?
O3 detects GHSA-269g-pwp5-87pp across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.