CVE-2021-32751
HighCVSS 7.5Exploitation Probability (EPSS)
High risk86th percentile - higher than 86% of all known CVEs
Summary
Gradle before version 7.2 contains a vulnerability to arbitrary code execution in start scripts generated by the `application` plugin and in the `gradlew` script. An attacker who can change environment variables for the user running the script can cause arbitrary code execution. This issue has been patched in Gradle 7.2 by removing the use of `eval` and requiring the use of the `bash` shell.
Risk Assessment
The risk is the possibility of gaining control over the system if an attacker can manipulate environment variables in CI/CD environments or on servers where Gradle scripts are executed. This could lead to compromising the integrity of the build or application startup process.
Recommendation
It is recommended to upgrade Gradle to version 7.2 or later immediately. If upgrading is not possible, restrict the ability to change environment variables for users executing the scripts, and consider manually removing the use of `eval` from start scripts.
Other vulnerabilities in Gradle
See all- CVE-2016-6199Critical
The ObjectSocketWrapper.java in Gradle 2.12 has a vulnerability that allows remote attackers to execute arbitrary code via a crafted serialized object.
- CVE-2023-44387Low
Vulnerability in Gradle when copying or archiving symlinked files. Gradle resolves the symlink but applies the permissions of the symlink itself instead of the linked file, resulting in files having too many permissions. Fixed in versions 7.6.3, 8.4 and above.
- CVE-2023-35947Medium
Gradle has a path traversal vulnerability when unpacking Tar archives, which may lead to overwriting important files in locations where the Gradle process has write permissions. An attacker can exploit this flaw by controlling the source of an archive or modifying the build to interact with a malicious archive.
- CVE-2023-35946Medium
Gradle, a build automation tool, has a vulnerability that allows files to be written to unintended locations in the filesystem through specially crafted dependency coordinates. This could lead to poisoning the dependency cache or overwriting important files.
- CVE-2021-29428High
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.
- CVE-2021-29429Medium
In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure, as remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. If you do not use the TextResourceFactory API, you are not vulnerable.
Original NVD description (English source)
Gradle is a build tool with a focus on build automation. In versions prior to 7.2, start scripts generated by the `application` plugin and the `gradlew` script are both vulnerable to arbitrary code execution when an attacker is able to change environment variables for the user running the script. This may impact those who use `gradlew` on Unix-like systems or use the scripts generated by Gradle in thieir application on Unix-like systems. For this vulnerability to be exploitable, an attacker needs to be able to set the value of particular environment variables and have those environment variables be seen by the vulnerable scripts. This issue has been patched in Gradle 7.2 by removing the use of `eval` and requiring the use of the `bash` shell. There are a few workarounds available. For CI/CD systems using the Gradle build tool, one may ensure that untrusted users are unable to change environment variables for the user that executes `gradlew`. If one is unable to upgrade to Gradle 7.2, one may generate a new `gradlew` script with Gradle 7.2 and use it for older versions of Gradle. Fpplications using start scripts generated by Gradle, one may ensure that untrusted users are unable to change environment variables for the user that executes the start script. A vulnerable start script could be manually patched to remove the use of `eval` or the use of environment variables that affect the application's command-line. If the application is simple enough, one may be able to avoid the use of the start scripts by running the application directly with Java command.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS