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.
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.
An issue was discovered in the Maven Extension plugin before 1.6 for Gradle Enterprise. The extension uses a socket connection to send serialized Java objects. Deserialization is not restricted to an allow-list, thus allowing an attacker to achieve code execution via a malicious deserialization gadget chain. The socket is not bound exclusively to localhost. The port this socket is assigned to is randomly selected and is not intentionally exposed to the public (either by design or documentation). This could potentially be used to achieve remote code execution and local privilege escalation.
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.
Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to code execution.
Gradle is a build tool. Dependency verification is a security feature in Gradle Build Tool that was introduced to allow validation of external dependencies either through their checksum or cryptographic signatures. In versions 6.2 through 7.4.2, there are some cases in which Gradle may skip that verification and accept a dependency that would otherwise fail the build as an untrusted external artifact. This can occur in two ways. When signature verification is disabled but the verification metadata contains entries for dependencies that only have a gpg element but no checksum element. When signature verification is enabled, the verification metadata contains entries for dependencies with a gpg element but there is no signature file on the remote repository. In both cases, the verification will accept the dependency, skipping signature verification and not complaining that the dependency has no checksum entry. For builds that are vulnerable, there are two risks. Gradle could download a malicious binary from a repository outside your organization due to name squatting. For those still using HTTP only and not HTTPS for downloading dependencies, the build could download a malicious library instead of the expected one. Gradle 7.5 patches this issue by making sure to run checksum verification if signature verification cannot be completed, whatever the reason. Two workarounds are available: Remove all gpg elements from dependency verification metadata if you disable signature validation and/or avoid adding gpg entries for dependencies that do not have signature files.
A directory traversal issue was discovered in Gradle gradle-enterprise-test-distribution-agent before 1.3.2, test-distribution-gradle-plugin before 1.3.2, and gradle-enterprise-maven-extension before 1.8.2. A malicious actor (with certain credentials) can perform a registration step such that crafted TAR archives lead to extraction of files into arbitrary filesystem locations.
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.
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.
End of life: 11/26/2018, End of support: 11/26/2018, Latest version: 4.10.3
End of life: 11/26/2018, End of support: 11/26/2018, Latest version: 4.10.3
End of life: 2/10/2023, End of support: 4/9/2021, Latest version: 6.9.4
End of life: 2/10/2023, End of support: 4/9/2021, Latest version: 6.9.4
End of life: 7/1/2014, End of support: 7/1/2014, Latest version: 1.12.0
End of life: 7/1/2014, End of support: 7/1/2014, Latest version: 1.12.0
End of life: 11/8/2019, End of support: 11/8/2019, Latest version: 5.6.4
End of life: 11/8/2019, End of support: 11/8/2019, Latest version: 5.6.4
End of life: 8/15/2016, End of support: 8/15/2016, Latest version: 2.14.1
End of life: 8/15/2016, End of support: 8/15/2016, Latest version: 2.14.1
End of life: 6/14/2017, End of support: 6/14/2017, Latest version: 3.5.1
End of life: 6/14/2017, End of support: 6/14/2017, Latest version: 3.5.1