CVE-2020-15250 is a vulnerability in JUnit 4's TemporaryFolder test rule, where temporary files and directories created during test execution were assigned overly permissive Unix file permissions — readable and writable by any local user on the system, not just the process running the tests. On a shared or multi-tenant build machine, that meant another local user could potentially read or tamper with data a test suite wrote to disk during a test run.
What exactly did TemporaryFolder do wrong?
TemporaryFolder created its files and directories using the platform default permissions rather than restricting access to the owning user, which on Unix-like systems could mean world-readable and world-writable depending on the system's umask settings. This is a test-scaffolding utility, not application logic — its entire job is to give test code a scratch directory that gets cleaned up automatically after the test runs. The bug meant that scratch directory wasn't as private as developers assumed:
- Any local user on a shared build server could potentially read files a test wrote to its temp directory during execution.
- A malicious local user, in specific race-condition scenarios, could tamper with those files before the test read them back.
- The exposure window was limited to the test's execution time, since
TemporaryFolderdeletes its directory afterward, but that window was often long enough to matter on CI infrastructure.
Who was actually affected?
Any project using JUnit 4 versions prior to 4.13.1 with test code that relied on TemporaryFolder for file-based test fixtures was affected, though real-world impact depended heavily on environment — a single-tenant CI runner with no other local users has a much smaller blast radius than a shared build server used by multiple teams or, in worse cases, external contributors. This is a useful reminder that not every dependency vulnerability requires production exposure to matter: a test-only dependency scoped entirely to your test suite can still carry meaningful risk on infrastructure you don't fully control.
Why does this CVE still surface in scans years later?
It still surfaces because JUnit 4 remains widely used — many large Java codebases haven't migrated to JUnit 5, and dependency graphs frequently retain an old JUnit 4 version pinned by a transitive test dependency long after the direct dependency was bumped. A software composition analysis scan run against an older pom.xml or build.gradle lockfile will flag it correctly even if the project's engineers haven't thought about their test dependencies in years, because nobody re-audits test-scope dependencies with the same rigor as production ones.
How is it fixed?
The fix is to upgrade to JUnit 4.13.1 or later, where TemporaryFolder was patched to restrict file permissions to the owning user. For teams that have already migrated to JUnit 5, this specific CVE doesn't apply directly, but it's worth checking whether any JUnit 4-based test modules remain in a mixed codebase, since partial migrations are common and easy to overlook in a dependency audit.
FAQ
Does CVE-2020-15250 affect production code?
No — it's scoped to JUnit's TemporaryFolder test rule, used only during test execution, not application runtime code. Its risk is limited to the CI/build environment where tests run.
What JUnit version fixes this?
JUnit 4.13.1 and later. Projects still pinned to 4.13.0 or earlier remain affected.
Should this be treated as low priority since it's test-only?
Not automatically. On shared or multi-tenant build infrastructure, a test-scope vulnerability can still expose data to other local users, so severity should be judged by your actual CI environment rather than by "test dependency" alone.
Does upgrading JUnit 4 to 4.13.1 require code changes?
Generally no — it's a patch-level fix to TemporaryFolder's internal permission handling, not an API change, so upgrading is typically a drop-in version bump.