CVE-2021-29428
mediumpriority · track · 31EPSS 0.005 · 45 %ileEUUSEPSS · scored 2026-10-27
In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · medium–high · 4.4–8.8
ssvc
A stakeholder decision — act, attend, or track — from exploitation and impact.
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (4)
Products and version ranges known to be affected.
advisories (1)
Vendor and ecosystem advisories describing this.
- BIT-gradle-2021-29428Local privilege escalation through system temporary directory2024-03-06vendor · osvUS
In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory.
also known as (3)
Other names and identifiers for this entity.
sources
Which sources assert this record, and when.
references (15)
External citations — patches, advisories, analysis.
- https://docs.gradle.org/7.0/release-notes.html#security-advisoriescnnvd
- https://github.com/gradle/gradle/pull/15240cnnvd
- https://github.com/gradle/gradle/pull/15654cnnvd
- https://github.com/gradle/gradle/security/advisories/GHSA-89qm-pxvm-p336cnnvd
- https://nvd.nist.gov/vuln/detail/CVE-2021-29428cnnvd
- https://packetstormsecurity.com/files/167222/Red-Hat-Security-Advisory-2022-4623-01.htmlcnnvd
- https://www.auscert.org.au/bulletins/ESB-2022.2471cnnvd
- https://docs.gradle.org/7.0/release-notes.html#security-advisoriesenisa_euvd
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan