gradle CVEs · Medium

Look up CVE IDs Status Exploitation Severity

Reset

Overview 17 matches · 3 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5

17matches 3in Waratek scope17.6% 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%

Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 3 17.6% Outside Waratek scope 0 0.0% Not applicable 14 82.4% Withdrawn CVE 0 0.0%

Critical 0 0.0% High 0 0.0% Medium 17 100.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%

blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 17 100.0% not established 0 0.0% unrecorded 0 0.0%

Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 17 100.0%

split by StatusSeverityProtectionExploit maturity peak 6 / quarter

Q2 19Q4 19Q2 20Q4 20Q2 21Q4 21Q2 22Q4 22Q2 23Q4 23

17 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.

CVE	Severity	Published▾	Status	Exploitation	Description
CVE-2023-42445	Medium	2023-10-06	Not applicable	No public exploit	Gradle is a build tool with a focus on build automation and support for multi-language development. In some cases, when Gradle parses XML files, resolving XML external entities is not disabled. Combined with an Out Of Band XXE attack (OOB-XXE), just parsing XML can lead to exfiltration of local text files to a remote server. Gradle parses XML files for several purposes. Most of the time, Gradle parses XML files it generated or were already present locally. Only Ivy XML descriptors and Maven POM files can be fetched from remote repositories and parsed by Gradle. In Gradle 7.6.3 and 8.4, resolving XML external entities has been disabled for all use cases to protect against this vulnerability. Gradle will now refuse to parse XML files that have XML external entities.
CVE-2023-44387	Medium	2023-10-05	Not applicable	No public exploit	Gradle is a build tool with a focus on build automation and support for multi-language development. When copying or archiving symlinked files, Gradle resolves them but applies the permissions of the symlink itself instead of the permissions of the linked file to the resulting file. This leads to files having too much permissions given that symlinks usually are world readable and writeable. While it is unlikely this results in a direct vulnerability for the impacted build, it may open up attack vectors depending on where build artifacts end up being copied to or un-archived. In versions 7.6.3, 8.4 and above, Gradle will now properly use the permissions of the file pointed at by the symlink to set permissions of the copied or archived file.
CVE-2023-35946	Medium	2023-06-30	Not applicable	No public exploit	Gradle is a build tool with a focus on build automation and support for multi-language development. When Gradle writes a dependency into its dependency cache, it uses the dependency's coordinates to compute a file location. With specially crafted dependency coordinates, Gradle can be made to write files into an unintended location. The file may be written outside the dependency cache or over another file in the dependency cache. This vulnerability could be used to poison the dependency cache or overwrite important files elsewhere on the filesystem where the Gradle process has write permissions. Exploiting this vulnerability requires an attacker to have control over a dependency repository used by the Gradle build or have the ability to modify the build's configuration. It is unlikely that this would go unnoticed. A fix has been released in Gradle 7.6.2 and 8.2 to protect against this vulnerability. Gradle will refuse to cache dependencies that have path traversal elements in their dependency coordinates. It is recommended that users upgrade to a patched version. If you are unable to upgrade to Gradle 7.6.2 or 8.2, `dependency verification` will make this vulnerability more difficult to exploit.
CVE-2022-31156	Medium	2022-07-14	Not applicable	No public exploit	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.
CVE-2022-27225	Medium	2022-03-16	Not applicable	No public exploit	Gradle Enterprise before 2021.4.3 relies on cleartext data transmission in some situations. It uses Keycloak for identity management services. During the sign-in process, Keycloak sets browser cookies that effectively provide remember-me functionality. For backwards compatibility with older Safari versions, Keycloak sets a duplicate of the cookie without the Secure attribute, which allows the cookie to be sent when accessing the location that cookie is set for via HTTP. This creates the potential for an attacker (with the ability to impersonate the Gradle Enterprise host) to capture the login session of a user by having them click an http:// link to the server, despite the real server requiring HTTPS.
CVE-2021-41590	Medium	2021-10-27	Not applicable	No public exploit	In Gradle Enterprise through 2021.3, probing of the server-side network environment can occur via an SMTP configuration test. The installation configuration user interface available to administrators allows testing the configured SMTP server settings. This test function can be used to identify the listening TCP ports available to the server, revealing information about the internal network environment.
CVE-2021-29429	Medium	2021-04-12	No exploit published	No public exploit	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.
CVE-2021-26719	Medium	2021-02-09	Not applicable	No public exploit	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.
CVE-2020-15774	Medium	2020-09-18	Not applicable	No public exploit	An issue was discovered in Gradle Enterprise 2018.5 - 2020.2.4. An attacker with physical access to the browser of a user who has recently logged in to Gradle Enterprise and since closed their browser could reopen their browser to access Gradle Enterprise as that user.
CVE-2020-15773	Medium	2020-09-18	Not applicable	No public exploit	An issue was discovered in Gradle Enterprise before 2020.2.4. Because of unrestricted cross-origin requests to read-only data in the Export API, an attacker can access data as a user (for the duration of the browser session) after previously explicitly authenticating with the API.
CVE-2020-15772	Medium	2020-09-18	Not applicable	No public exploit	An issue was discovered in Gradle Enterprise 2018.5 - 2020.2.4. When configuring Gradle Enterprise to integrate with a SAML identity provider, an XML metadata file can be uploaded by an administrator. The server side processing of this file dereferences XML External Entities (XXE), allowing a remote attacker with administrative access to perform server side request forgery.
CVE-2020-15770	Medium	2020-09-18	Not applicable	No public exploit	An issue was discovered in Gradle Enterprise 2018.5. An attacker can potentially make repeated attempts to guess a local user's password, due to lack of lock-out after excessive failed logins.
CVE-2020-15769	Medium	2020-09-18	Not applicable	No public exploit	An issue was discovered in Gradle Enterprise 2020.2 - 2020.2.4. An XSS issue exists via the request URL.
CVE-2020-15767	Medium	2020-09-18	Not applicable	No public exploit	An issue was discovered in Gradle Enterprise before 2020.2.5. The cookie used to convey the CSRF prevention token is not annotated with the “secure” attribute, which allows an attacker with the ability to MITM plain HTTP requests to obtain it, if the user mistakenly uses a HTTP instead of HTTPS address to access the server. This cookie value could then be used to perform CSRF.
CVE-2020-7599	Medium	2020-03-30	No exploit published	No public exploit	All versions of com.gradle.plugin-publish before 0.11.0 are vulnerable to Insertion of Sensitive Information into Log File. When a plugin author publishes a Gradle plugin while running Gradle with the --info log level flag, the Gradle Logger logs an AWS pre-signed URL. If this build log is publicly visible (as it is in many popular public CI systems like TravisCI) this AWS pre-signed URL would allow a malicious actor to replace a recently uploaded plugin with their own.
CVE-2019-16370	Medium	2019-09-16	No exploit published	No public exploit	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.
CVE-2019-11065	Medium	2019-04-10	Not applicable	No public exploit	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.

CVE

Severity

Published▾

Status

Exploitation

Description

CVE-2023-42445

Medium

2023-10-06

Not applicable

No public exploit

Gradle is a build tool with a focus on build automation and support for multi-language development. In some cases, when Gradle parses XML files, resolving XML external entities is not disabled. Combined with an Out Of Band XXE attack (OOB-XXE), just parsing XML can lead to exfiltration of local text files to a remote server. Gradle parses XML files for several purposes. Most of the time, Gradle parses XML files it generated or were already present locally. Only Ivy XML descriptors and Maven POM files can be fetched from remote repositories and parsed by Gradle. In Gradle 7.6.3 and 8.4, resolving XML external entities has been disabled for all use cases to protect against this vulnerability. Gradle will now refuse to parse XML files that have XML external entities.

CVE-2023-44387

Medium

2023-10-05

Not applicable

No public exploit

Gradle is a build tool with a focus on build automation and support for multi-language development. When copying or archiving symlinked files, Gradle resolves them but applies the permissions of the symlink itself instead of the permissions of the linked file to the resulting file. This leads to files having too much permissions given that symlinks usually are world readable and writeable. While it is unlikely this results in a direct vulnerability for the impacted build, it may open up attack vectors depending on where build artifacts end up being copied to or un-archived. In versions 7.6.3, 8.4 and above, Gradle will now properly use the permissions of the file pointed at by the symlink to set permissions of the copied or archived file.

CVE-2023-35946

Medium

2023-06-30

Not applicable

No public exploit

Gradle is a build tool with a focus on build automation and support for multi-language development. When Gradle writes a dependency into its dependency cache, it uses the dependency's coordinates to compute a file location. With specially crafted dependency coordinates, Gradle can be made to write files into an unintended location. The file may be written outside the dependency cache or over another file in the dependency cache. This vulnerability could be used to poison the dependency cache or overwrite important files elsewhere on the filesystem where the Gradle process has write permissions. Exploiting this vulnerability requires an attacker to have control over a dependency repository used by the Gradle build or have the ability to modify the build's configuration. It is unlikely that this would go unnoticed. A fix has been released in Gradle 7.6.2 and 8.2 to protect against this vulnerability. Gradle will refuse to cache dependencies that have path traversal elements in their dependency coordinates. It is recommended that users upgrade to a patched version. If you are unable to upgrade to Gradle 7.6.2 or 8.2, `dependency verification` will make this vulnerability more difficult to exploit.

CVE-2022-31156

Medium

2022-07-14

Not applicable

No public exploit

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.

CVE-2022-27225

Medium

2022-03-16

Not applicable

No public exploit

Gradle Enterprise before 2021.4.3 relies on cleartext data transmission in some situations. It uses Keycloak for identity management services. During the sign-in process, Keycloak sets browser cookies that effectively provide remember-me functionality. For backwards compatibility with older Safari versions, Keycloak sets a duplicate of the cookie without the Secure attribute, which allows the cookie to be sent when accessing the location that cookie is set for via HTTP. This creates the potential for an attacker (with the ability to impersonate the Gradle Enterprise host) to capture the login session of a user by having them click an http:// link to the server, despite the real server requiring HTTPS.

CVE-2021-41590

Medium

2021-10-27

Not applicable

No public exploit

In Gradle Enterprise through 2021.3, probing of the server-side network environment can occur via an SMTP configuration test. The installation configuration user interface available to administrators allows testing the configured SMTP server settings. This test function can be used to identify the listening TCP ports available to the server, revealing information about the internal network environment.

CVE-2021-29429

Medium

2021-04-12

No exploit published

No public exploit

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.

CVE-2021-26719

Medium

2021-02-09

Not applicable

No public exploit

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.

CVE-2020-15774

Medium

2020-09-18

Not applicable

No public exploit

An issue was discovered in Gradle Enterprise 2018.5 - 2020.2.4. An attacker with physical access to the browser of a user who has recently logged in to Gradle Enterprise and since closed their browser could reopen their browser to access Gradle Enterprise as that user.

CVE-2020-15773

Medium

2020-09-18

Not applicable

No public exploit

An issue was discovered in Gradle Enterprise before 2020.2.4. Because of unrestricted cross-origin requests to read-only data in the Export API, an attacker can access data as a user (for the duration of the browser session) after previously explicitly authenticating with the API.

CVE-2020-15772

Medium

2020-09-18

Not applicable

No public exploit

An issue was discovered in Gradle Enterprise 2018.5 - 2020.2.4. When configuring Gradle Enterprise to integrate with a SAML identity provider, an XML metadata file can be uploaded by an administrator. The server side processing of this file dereferences XML External Entities (XXE), allowing a remote attacker with administrative access to perform server side request forgery.

CVE-2020-15770

Medium

2020-09-18

Not applicable

No public exploit

An issue was discovered in Gradle Enterprise 2018.5. An attacker can potentially make repeated attempts to guess a local user's password, due to lack of lock-out after excessive failed logins.

CVE-2020-15769

Medium

2020-09-18

Not applicable

No public exploit

An issue was discovered in Gradle Enterprise 2020.2 - 2020.2.4. An XSS issue exists via the request URL.

CVE-2020-15767

Medium

2020-09-18

Not applicable

No public exploit

An issue was discovered in Gradle Enterprise before 2020.2.5. The cookie used to convey the CSRF prevention token is not annotated with the “secure” attribute, which allows an attacker with the ability to MITM plain HTTP requests to obtain it, if the user mistakenly uses a HTTP instead of HTTPS address to access the server. This cookie value could then be used to perform CSRF.

CVE-2020-7599

Medium

2020-03-30

No exploit published

No public exploit

All versions of com.gradle.plugin-publish before 0.11.0 are vulnerable to Insertion of Sensitive Information into Log File. When a plugin author publishes a Gradle plugin while running Gradle with the --info log level flag, the Gradle Logger logs an AWS pre-signed URL. If this build log is publicly visible (as it is in many popular public CI systems like TravisCI) this AWS pre-signed URL would allow a malicious actor to replace a recently uploaded plugin with their own.

CVE-2019-16370

Medium

2019-09-16

No exploit published

No public exploit

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.

CVE-2019-11065

Medium

2019-04-10

Not applicable

No public exploit

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.