How severe is CVE-2020-15250?

CVE-2020-15250 has a CVSS score of 5.5/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by CVE-2020-15250?

CVE-2020-15250 affects the following packages: junit:junit (Maven). Ecosystems affected: Maven.

How do I fix CVE-2020-15250?

Update junit:junit to 4.13.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2020-15250 is resolved across your whole dependency graph.

How do I detect CVE-2020-15250 in my Maven dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for junit:junit, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2020-15250 if there is no patch (or I can't update yet)?

Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.

Is CVE-2020-15250 actively exploited in the wild?

Yes. There are 1 known exploit references for CVE-2020-15250, including 1 in-the-wild exploitation observed on GitHub and other sources. Treat this as actively exploitable and prioritize patching immediately. All exploit code should only be run in an isolated sandbox environment for research or authorized testing — never against production systems without explicit written authorization.

What is the EPSS score for CVE-2020-15250?

CVE-2020-15250 has an EPSS (Exploit Prediction Scoring System) score of 1.7%, placing it in the 76th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2020-15250?

CVE-2020-15250 is classified as Information Exposure (CWE-200), CWE-732 (CWE-732). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2020-15250 published, and has it been updated?

CVE-2020-15250 was published on October 12, 2020 and was last updated on July 9, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

☕

☕ Maven

Not in CISA KEV

MEDIUM severity

CVE-2020-15250 — junit

MEDIUMFix: junit-team/junit4@610155b

CVE-2020-15250 is a medium-severity (CVSS 5.5) Information Exposure vulnerability in junit:junit. 1 public exploit reference exists, so weaponization risk is real. A fix is available for junit:junit — see the affected versions and patch details below.

TemporaryFolder on unix-like systems does not limit access to created files

Also known asGHSA-269g-pwp5-87pp

Published

Oct 12, 2020

Updated

Jul 9, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

1 known

Exploitation data as of Oct 8, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2020-15250.

EPSS Exploitation Probability

via FIRST.org ↗

1.7%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs76th percentile — riskier than 76% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2020-15250 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected

☕junit:junit

Real-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

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

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
☕Maven	`junit:junit`	≥ 4.7&&< 4.13.1	4.13.1`junit:junit:4.13.1`

Affected Products

4 products · 4 configurations

Application

plutoapache

< 3.1.1

range

debian linuxdebian

1 version

9.0

Application

junit4junit

≥ 4.7 && < 4.13.1

range

Application

communications cloud native core policyoracle

1 version

1.14.0

Exploits & PoCs

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.

In JUnit4 from version 4.7 and before 4.13.1, the test rule TemporaryFol…

github.comNVDJul 2021

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for junit:junit, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update junit:junit to 4.13.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2020-15250 is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.

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.

Red HatLow

Product	Fixed in	Advisory
Red Hat Fuse 7.11	`junit4`	RHSA-2022:5532

UbuntuMEDIUM

USN-4731-1Ubuntu

Frequently Asked Questions

### Vulnerability The JUnit4 test rule [TemporaryFolder](https://junit.org/junit4/javadoc/4.13/org/junit/rules/TemporaryFolder.html) contains a local information disclosure vulnerability. Example of vulnerable code: ```java 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 F

O3 Security · Impact-Aware SCA

Is CVE-2020-15250 in your dependencies?

Find it across Maven, including transitive dependencies.

Scan my dependencies How O3 SCA works