Gradle Gradle

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

Products by Gradle Sorted by Most Security Vulnerabilities since 2018

Gradle Enterprise21 vulnerabilities

Gradle21 vulnerabilities

Gradle Build Cache Node2 vulnerabilities

Gradle Enterprise Cache Node2 vulnerabilities

Gradle Maven2 vulnerabilities

Gradle Build Action1 vulnerability

Gradle Enterprise1 vulnerability

Gradle Plugin Publishing1 vulnerability

Gradle Test Distribution1 vulnerability

By the Year

In 2024 there have been 1 vulnerability in Gradle with an average score of 9.8 out of ten. Last year Gradle had 6 security vulnerabilities published. Right now, Gradle is on track to have less security vulnerabilities in 2024 than it did last year. However, the average CVE base score of the vulnerabilities in 2024 is greater by 2.85.

Year Vulnerabilities Average Score
2024 1 9.80
2023 6 6.95
2022 9 7.33
2021 12 7.28
2020 13 6.78
2019 5 8.24
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 2023.1, a remote attacker may be able to gain access to a new installation (in certain installation scenarios)

CVE-2023-49238 9.8 - Critical - January 09, 2024

In Gradle Enterprise before 2023.1, a remote attacker may be able to gain access to a new installation (in certain installation scenarios) because of a non-unique initial system user password. Although this password must be changed upon the first login, it is possible that an attacker logs in before the legitimate administrator logs in.

Weak Password Requirements

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

CVE-2023-42445 5.3 - Medium - October 06, 2023

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.

XXE

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

CVE-2023-44387 6.5 - Medium - October 05, 2023

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.

Incorrect Permission Assignment for Critical Resource

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

CVE-2023-35947 8.1 - High - June 30, 2023

Gradle is a build tool with a focus on build automation and support for multi-language development. In affected versions when unpacking Tar archives, Gradle did not check that files could be written outside of the unpack location. This could lead to important files being overwritten anywhere the Gradle process has write permissions. For a build reading Tar entries from a Tar archive, this issue could allow Gradle to disclose information from sensitive files through an arbitrary file read. To exploit this behavior, an attacker needs to either control the source of an archive already used by the build or modify the build to interact with a malicious archive. 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. Starting from these versions, Gradle will refuse to handle Tar archives which contain path traversal elements in a Tar entry name. Users are advised to upgrade. There are no known workarounds for this vulnerability. ### Impact This is a path traversal vulnerability when Gradle deals with Tar archives, often referenced as TarSlip, a variant of ZipSlip. * When unpacking Tar archives, Gradle did not check that files could be written outside of the unpack location. This could lead to important files being overwritten anywhere the Gradle process has write permissions. * For a build reading Tar entries from a Tar archive, this issue could allow Gradle to disclose information from sensitive files through an arbitrary file read. To exploit this behavior, an attacker needs to either control the source of an archive already used by the build or modify the build to interact with a malicious archive. It is unlikely that this would go unnoticed. Gradle uses Tar archives for its [Build Cache](https://docs.gradle.org/current/userguide/build_cache.html). These archives are safe when created by Gradle. But if an attacker had control of a remote build cache server, they could inject malicious build cache entries that leverage this vulnerability. This attack vector could also be exploited if a man-in-the-middle can be performed between the remote cache and the build. ### Patches A fix has been released in Gradle 7.6.2 and 8.2 to protect against this vulnerability. Starting from these versions, Gradle will refuse to handle Tar archives which contain path traversal elements in a Tar entry name. It is recommended that users upgrade to a patched version. ### Workarounds There is no workaround. * If your build deals with Tar archives that you do not fully trust, you need to inspect them to confirm they do not attempt to leverage this vulnerability. * If you use the Gradle remote build cache, make sure only trusted parties have write access to it and that connections to the remote cache are properly secured. ### References * [CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) * [Gradle Build Cache](https://docs.gradle.org/current/userguide/build_cache.html) * [ZipSlip](https://security.snyk.io/research/zip-slip-vulnerability)

Directory traversal

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

CVE-2023-35946 5.5 - Medium - June 30, 2023

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.

Directory traversal

Gradle Build Action allows users to execute a Gradle Build in their GitHub Actions workflow

CVE-2023-30853 6.5 - Medium - April 28, 2023

Gradle Build Action allows users to execute a Gradle Build in their GitHub Actions workflow. A vulnerability impacts GitHub workflows using the Gradle Build Action prior to version 2.4.2 that have executed the Gradle Build Tool with the configuration cache enabled, potentially exposing secrets configured for the repository. Secrets configured for GitHub Actions are normally passed to the Gradle Build Tool via environment variables. Due to the way that the Gradle Build Tool records these environment variables, they may be persisted into an entry in the GitHub Actions cache. This data stored in the GitHub Actions cache can be read by a GitHub Actions workflow running in an untrusted context, such as that running for a Pull Request submitted by a developer via a repository fork. This vulnerability was discovered internally through code review, and we have not seen any evidence of it being exploited in the wild. However, in addition to upgrading the Gradle Build Action, affected users should delete any potentially vulnerable cache entries and may choose to rotate any potentially affected secrets. Gradle Build Action v2.4.2 and newer no longer saves this sensitive data for later use, preventing ongoing leakage of secrets via the GitHub Actions Cache. While upgrading to the latest version of the Gradle Build Action will prevent leakage of secrets going forward, additional actions may be required due to current or previous GitHub Actions Cache entries containing this information. Current cache entries will remain vulnerable until they are forcibly deleted or they expire naturally after 7 days of not being used. Potentially vulnerable entries can be easily identified in the GitHub UI by searching for a cache entry with key matching `configuration-cache-*`. The maintainers recommend that users of the Gradle Build Action inspect their list of cache entries and manually delete any that match this pattern. While maintainers have not seen any evidence of this vulnerability being exploited, they recommend cycling any repository secrets if you cannot be certain that these have not been compromised. Compromise could occur if a user runs a GitHub Actions workflow for a pull request attempting to exploit this data. Warning signs to look for in a pull request include: - Making changes to GitHub Actions workflow files in a way that may attempt to read/extract data from the Gradle User Home or `<project-root>/.gradle` directories. - Making changes to Gradle build files or other executable files that may be invoked by a GitHub Actions workflow, in a way that may attempt to read/extract information from these locations. Some workarounds to limit the impact of this vulnerability are available: - If the Gradle project does not opt-in to using the configuration cache, then it is not vulnerable. - If the Gradle project does opt-in to using the configuration-cache by default, then the `--no-configuration-cache` command-line argument can be used to disable this feature in a GitHub Actions workflow. In any case, we recommend that users carefully inspect any pull request before approving the execution of GitHub Actions workflows. It may be prudent to require approval for all PRs from external contributors.

Cleartext Storage of Sensitive Information

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

CVE-2023-26053 9.8 - Critical - March 02, 2023

Gradle is a build tool with a focus on build automation and support for multi-language development. This is a collision attack on long IDs (64bits) for PGP keys. Users of dependency verification in Gradle are vulnerable if they use long IDs for PGP keys in a `trusted-key` or `pgp` element in their dependency verification metadata file. The fix is to fail dependency verification if anything but a fingerprint is used in a trust element in dependency verification metadata. The problem is fixed in Gradle 8.0 and above. The problem is also patched in Gradle 6.9.4 and 7.6.1. As a workaround, use only full fingerprint IDs for `trusted-key` or `pgp` element in the metadata is a protection against this issue.

Inclusion of Functionality from Untrusted Control Sphere

A credential-exposure vulnerability in the support-bundle mechanism in Gradle Enterprise 2022.3 through 2022.3.3

CVE-2022-41575 7.5 - High - October 21, 2022

A credential-exposure vulnerability in the support-bundle mechanism in Gradle Enterprise 2022.3 through 2022.3.3 allows remote attackers to access a subset of application data (e.g., cleartext credentials). This is fixed in 2022.3.3.

Insufficiently Protected Credentials

An access-control vulnerability in Gradle Enterprise 2022.4 through 2022.3.1

CVE-2022-41574 7.5 - High - October 07, 2022

An access-control vulnerability in Gradle Enterprise 2022.4 through 2022.3.1 allows remote attackers to prevent backups from occurring, and send emails with arbitrary text content to the configured installation-administrator contact address, via HTTP access to an accidentally exposed internal endpoint. This is fixed in 2022.3.2.

AuthZ

Gradle is a build tool

CVE-2022-31156 4.4 - Medium - July 14, 2022

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.

Improper Verification of Cryptographic Signature

Gradle Enterprise through 2022.2.2 has Incorrect Access Control

CVE-2022-30587 7.5 - High - June 06, 2022

Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to information disclosure.

Insufficiently Protected Credentials

Gradle Enterprise through 2022.2.2 has Incorrect Access Control

CVE-2022-30586 7.2 - High - June 06, 2022

Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to code execution.

Information Disclosure

Gradle Enterprise before 2022.1 allows remote code execution if the installation process did not specify an initial configuration file

CVE-2022-27919 9.8 - Critical - March 25, 2022

Gradle Enterprise before 2022.1 allows remote code execution if the installation process did not specify an initial configuration file. The configuration allows certain anonymous access to administration and an API.

Incorrect Default Permissions

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.)

Incorrect Default Permissions

Gradle Enterprise before 2021.4.3 relies on cleartext data transmission in some situations

CVE-2022-27225 6.5 - Medium - March 16, 2022

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.

Missing Encryption of Sensitive Data

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.3 (and Enterprise Build Cache Node before 10.0)

CVE-2021-41589 9.8 - Critical - October 27, 2021

In Gradle Enterprise before 2021.3 (and Enterprise Build Cache Node before 10.0), there is potential cache poisoning and remote code execution when running the build cache node with its default configuration. This configuration allows anonymous access to the configuration user interface and anonymous write access to the build cache. If access control to the build cache is not changed from the default open configuration, a malicious actor with network access can populate the cache with manipulated entries that may execute malicious code as part of a build process. This applies to the build cache provided with Gradle Enterprise and the separate build cache node service if used. If access control to the user interface is not changed from the default open configuration, a malicious actor can undo build cache access control in order to populate the cache with manipulated entries that may execute malicious code as part of a build process. This does not apply to the build cache provided with Gradle Enterprise, but does apply to the separate build cache node service if used.

Incorrect Permission Assignment for Critical Resource

In Gradle Enterprise through 2021.3, probing of the server-side network environment can occur via an SMTP configuration test

CVE-2021-41590 5.3 - Medium - October 27, 2021

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.

An issue was discovered in Gradle Enterprise before 2021.1.2

CVE-2021-41619 7.2 - High - October 27, 2021

An issue was discovered in Gradle Enterprise before 2021.1.2. There is potential remote code execution via the application startup configuration. The installation configuration user interface (available to administrators) allows specifying arbitrary Java Virtual Machine startup options. Some of these options, such as -XX:OnOutOfMemoryError, allow specifying a command to be run on the host. This can be abused to run arbitrary commands on the host, should an attacker gain administrative access to the application.

Code Injection

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

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, 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

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 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, 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 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

A directory traversal issue was discovered in Gradle gradle-enterprise-test-distribution-agent before 1.3.2

CVE-2021-26719 6.5 - Medium - February 09, 2021

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.

Directory traversal

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.

An issue was discovered in Gradle Enterprise before 2020.2.4

CVE-2020-15773 6.5 - Medium - September 18, 2020

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.

Origin Validation Error

An issue was discovered in Gradle Enterprise 2018.2 - 2020.2.4

CVE-2020-15776 8.8 - High - September 18, 2020

An issue was discovered in Gradle Enterprise 2018.2 - 2020.2.4. The CSRF prevention token is stored in a request cookie that is not annotated as HttpOnly. An attacker with the ability to execute arbitrary code in a user's browser could impose an arbitrary value for this token, allowing them to perform cross-site request forgery.

An issue was discovered in Gradle Enterprise 2017.1 - 2020.2.4

CVE-2020-15775 7.5 - High - September 18, 2020

An issue was discovered in Gradle Enterprise 2017.1 - 2020.2.4. The /usage page of Gradle Enterprise conveys high level build information such as project names and build counts over time. This page is incorrectly viewable anonymously.

Insecure Storage of Sensitive Information

An issue was discovered in Gradle Enterprise 2018.5 - 2020.2.4

CVE-2020-15774 6.8 - Medium - September 18, 2020

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.

Insufficient Session Expiration

An issue was discovered in Gradle Enterprise 2018.2 and Gradle Enterprise Build Cache Node 4.1

CVE-2020-15771 7.5 - High - September 18, 2020

An issue was discovered in Gradle Enterprise 2018.2 and Gradle Enterprise Build Cache Node 4.1. Cross-site transmission of cookie containing CSRF token allows remote attacker to bypass CSRF mitigation.

Missing Encryption of Sensitive Data

An issue was discovered in Gradle Enterprise 2018.5 - 2020.2.4

CVE-2020-15772 4.9 - Medium - September 18, 2020

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.

XXE

An issue was discovered in Gradle Enterprise 2018.5

CVE-2020-15770 5.5 - Medium - September 18, 2020

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.

Improper Restriction of Excessive Authentication Attempts

An issue was discovered in Gradle Enterprise 2020.2 - 2020.2.4

CVE-2020-15769 6.1 - Medium - September 18, 2020

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

XSS

An issue was discovered in Gradle Enterprise 2017.3 - 2020.2.4 and Gradle Enterprise Build Cache Node 1.0 - 9.2

CVE-2020-15768 7.5 - High - September 18, 2020

An issue was discovered in Gradle Enterprise 2017.3 - 2020.2.4 and Gradle Enterprise Build Cache Node 1.0 - 9.2. Unrestricted HTTP header reflection in Gradle Enterprise allows remote attackers to obtain authentication cookies, if they are able to discover a separate XSS vulnerability. This potentially allows an attacker to impersonate another user. Gradle Enterprise affected application request paths:/info/headers, /cache-info/headers, /admin-info/headers, /distribution-broker-info/headers. Gradle Enterprise Build Cache Node affected application request paths:/cache-node-info/headers.

An issue was discovered in Gradle Enterprise before 2020.2.5

CVE-2020-15767 5.3 - Medium - September 18, 2020

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.

Missing Encryption of Sensitive Data

An issue was discovered in the Maven Extension plugin before 1.6 for Gradle Enterprise

CVE-2020-15777 7.8 - High - August 25, 2020

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.

Marshaling, Unmarshaling

All versions of com.gradle.plugin-publish before 0.11.0 are vulnerable to Insertion of Sensitive Information into Log File

CVE-2020-7599 6.5 - Medium - March 30, 2020

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.

Insertion of Sensitive Information into Log File

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

In Gradle Enterprise before 2018.5.2, Build Cache Nodes

CVE-2019-11403 9.8 - Critical - April 22, 2019

In Gradle Enterprise before 2018.5.2, Build Cache Nodes would reflect the configured password back when viewing the HTML page source of the settings page.

Information Disclosure

In Gradle Enterprise before 2018.5.3

CVE-2019-11402 9.8 - Critical - April 22, 2019

In Gradle Enterprise before 2018.5.3, Build Cache Nodes did not store the credentials at rest in an encrypted format.

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.

Built by Foundeo Inc., with data from the National Vulnerability Database (NVD), Icons by Icons8. Privacy Policy. Use of this site is governed by the Legal Terms
Disclaimer
CONTENT ON THIS WEBSITE IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. Always check with your vendor for the most up to date, and accurate information.