Gradle Gradle

Do you want an email whenever new security vulnerabilities are reported in Gradle?

By the Year

In 2022 there have been 2 vulnerabilities in Gradle with an average score of 7.8 out of ten. Last year Gradle had 8 security vulnerabilities published. Right now, Gradle is on track to have less security vulnerabilities in 2022 than it did last year. However, the average CVE base score of the vulnerabilities in 2022 is greater by 0.48.

Year Vulnerabilities Average Score
2022 2 7.80
2021 8 7.33
2020 1 7.50
2019 3 7.20
2018 0 0.00

It may take a day or so for new Gradle vulnerabilities to show up in the stats or in the list of recent security vulnerabilties. Additionally vulnerabilities may be tagged under a different product or component name.

Recent Gradle Security Vulnerabilities

In Gradle Enterprise before 2021.4.2, the default built-in build cache configuration allowed anonymous write access

CVE-2022-25364 8.1 - High - March 17, 2022

In Gradle Enterprise before 2021.4.2, the default built-in build cache configuration allowed anonymous write access. If this was not manually changed, a malicious actor with network access to the build cache could potentially populate it with manipulated entries that execute malicious code as part of a build. As of 2021.4.2, the built-in build cache is inaccessible-by-default, requiring explicit configuration of its access-control settings before it can be used. (Remote build cache nodes are unaffected as they are inaccessible-by-default.)

AuthZ

Gradle is a build tool with a focus on build automation and support for multi-language development

CVE-2022-23630 7.5 - High - February 10, 2022

Gradle is a build tool with a focus on build automation and support for multi-language development. In some cases, Gradle may skip that verification and accept a dependency that would otherwise fail the build as an untrusted external artifact. This occurs when dependency verification is disabled on one or more configurations and those configurations have common dependencies with other configurations that have dependency verification enabled. If the configuration that has dependency verification disabled is resolved first, Gradle does not verify the common dependencies for the configuration that has dependency verification enabled. Gradle 7.4 fixes that issue by validating artifacts at least once if they are present in a resolved configuration that has dependency verification active. For users who cannot update either do not use `ResolutionStrategy.disableDependencyVerification()` and do not use plugins that use that method to disable dependency verification for a single configuration or make sure resolution of configuration that disable that feature do not happen in builds that resolve configuration where the feature is enabled.

Inclusion of Functionality from Untrusted Control Sphere

In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks

CVE-2021-41587 7.5 - High - September 24, 2021

In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks can potentially discover credentials for other resources.

XSPA

In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks

CVE-2021-41586 7.5 - High - September 24, 2021

In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks can potentially reset the system user password.

XSPA

In Gradle Enterprise before 2021.1.3, a crafted request can trigger deserialization of arbitrary unsafe Java objects

CVE-2021-41588 8.1 - High - September 24, 2021

In Gradle Enterprise before 2021.1.3, a crafted request can trigger deserialization of arbitrary unsafe Java objects. The attacker must have the encryption and signing keys.

Marshaling, Unmarshaling

Gradle Enterprise before 2021.1.3 can

CVE-2021-41584 7.5 - High - September 24, 2021

Gradle Enterprise before 2021.1.3 can allow unauthorized viewing of a response (information disclosure of possibly sensitive build/configuration details) via a crafted HTTP request with the X-Gradle-Enterprise-Ajax-Request header.

Information Disclosure

Gradle is a build tool with a focus on build automation

CVE-2021-32751 7.5 - High - July 20, 2021

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.

Shell injection

In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions

CVE-2021-29428 7.8 - High - April 13, 2021

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.

Creation of Temporary File With Insecure Permissions

In Gradle from version 5.1 and before version 7.0 there is a vulnerability

CVE-2021-29427 7.2 - High - April 13, 2021

In Gradle from version 5.1 and before version 7.0 there is a vulnerability which can lead to information disclosure and/or dependency poisoning. Repository content filtering is a security control Gradle introduced to help users specify what repositories are used to resolve specific dependencies. This feature was introduced in the wake of the "A Confusing Dependency" blog post. In some cases, Gradle may ignore content filters and search all repositories for dependencies. This only occurs when repository content filtering is used from within a `pluginManagement` block in a settings file. This may change how dependencies are resolved for Gradle plugins and build scripts. For builds that are vulnerable, there are two risks: 1) Information disclosure: Gradle could make dependency requests to repositories outside your organization and leak internal package identifiers. 2) Dependency poisoning/Dependency confusion: Gradle could download a malicious binary from a repository outside your organization due to name squatting. For a full example and more details refer to the referenced GitHub Security Advisory. The problem has been patched and released with Gradle 7.0. Users relying on this feature should upgrade their build as soon as possible. As a workaround, users may use a company repository which has the right rules for fetching packages from public repositories, or use project level repository content filtering, inside `buildscript.repositories`. This option is available since Gradle 5.1 when the feature was introduced.

Inclusion of Functionality from Untrusted Control Sphere

In Gradle before version 7.0, files created with open permissions in the system temporary directory can

CVE-2021-29429 5.5 - Medium - April 12, 2021

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. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the `TextResourceFactory` API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, 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.

Insecure Temporary File

As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the permissions of temporary files it created so

CVE-2020-11979 7.5 - High - October 01, 2020

As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the permissions of temporary files it created so that only the current user was allowed to access them. Unfortunately the fixcrlf task deleted the temporary file and created a new one without said protection, effectively nullifying the effort. This would still allow an attacker to inject modified source files into the build process.

The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one

CVE-2019-16370 5.9 - Medium - September 16, 2019

The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.

Improper Input Validation

The HTTP client in Gradle before 5.6 sends authentication credentials originally destined for the configured host

CVE-2019-15052 9.8 - Critical - August 14, 2019

The HTTP client in Gradle before 5.6 sends authentication credentials originally destined for the configured host. If that host returns a 30x redirect, Gradle also sends those credentials to all subsequent hosts that the request redirects to. This is similar to CVE-2018-1000007.

Insufficiently Protected Credentials

Gradle versions from 1.4 to 5.3.1 use an insecure HTTP URL to download dependencies when the built-in JavaScript or CoffeeScript Gradle plugins are used

CVE-2019-11065 5.9 - Medium - April 10, 2019

Gradle versions from 1.4 to 5.3.1 use an insecure HTTP URL to download dependencies when the built-in JavaScript or CoffeeScript Gradle plugins are used. Dependency artifacts could have been maliciously compromised by a MITM attack against the ajax.googleapis.com web site.

Stay on top of Security Vulnerabilities

Want an email whenever new vulnerabilities are published for Fedora Project Fedora or by Gradle? Click the Watch button to subscribe.

Gradle
Vendor

Gradle
Product

subscribe