Apache Ant could allow a remote authenticated attacker to bypass security restrictions, caused by an insecure temporary file flaw. By sending a specially-crafted request, an attacker could exploit this vulnerability to inject modified source files into the build process.

Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. 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. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory.

In net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the Native.get(Class<>) method was called, without calling Native.init(File) first, with a non-null argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe.

Gradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, relying on copying the binaries to the system temporary directory. Any execution of Gradle exposed this exploit. Users of Windows or modern versions of macOS are not vulnerable, nor are users of a Unix-like operating system with the "sticky" bit set or noexec on their system temporary directory vulnerable. This problem was fixed in Gradle 8.12.1. Gradle 8.13 release also upgrades to a version of the native library that no longer has that bug. Some workarounds are available. On Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. Mounting /tmp as noexec will prevent Gradle 8.12 from starting. Those who are are unable to change the permissions of the system temporary directory 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.

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. 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') Gradle Build Cache ZipSlip

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.

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.

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.

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.

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

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.

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

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.

ObjectSocketWrapper.java in Gradle 2.12 allows remote attackers to execute arbitrary code via a crafted serialized object.

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.

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.

gradle-completion provides Bash and Zsh completion support for Gradle. A command injection vulnerability was found in gradle-completion up to and including 9.3.0 that allows arbitrary code execution when a user triggers Bash tab completion in a project containing a malicious Gradle build file. The gradle-completion script for Bash fails to adequately sanitize Gradle task names and task descriptions, allowing command injection via a malicious Gradle build file when the user completes a command in Bash (without them explicitly running any task in the build). For example, given a task description that includes a string between backticks, then that string would be evaluated as a command when presenting the task description in the completion list. While task execution is the core feature of Gradle, this inherent execution may lead to unexpected outcomes. The vulnerability does not affect zsh completion. The first patched version is 9.3.1. As a workaround, it is possible and effective to temporarily disable bash completion for Gradle by removing gradle-completion from .bashrc or .bashprofile.

Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. When resolving dependencies in versions before 9.3.0, some exceptions were not treated as fatal errors and would not cause a repository to be disabled. If a build encountered one of these exceptions, Gradle would continue to the next repository in the list and potentially resolve dependencies from a different repository. If a Gradle build used an unresolvable host name, Gradle would continue to work as long as all dependencies could be resolved from another repository. An unresolvable host name could be caused by allowing a repository's domain name registration to lapse or typo-ing the real domain name. This behavior could allow an attacker to register a service under the host name used by the build and serve malicious artifacts. The attack requires the repository to be listed before others in the build configuration. Gradle has introduced a change in behavior in Gradle 9.3.0 to stop searching other repositories when encountering these errors.

Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. When resolving dependencies in versions before 9.3.0, some exceptions were not treated as fatal errors and would not cause a repository to be disabled. If a build encountered one of these exceptions, Gradle would continue to the next repository in the list and potentially resolve dependencies from a different repository. An exception like NoHttpResponseException can indicate transient errors. If the errors persist after a maximum number of retries, Gradle would continue to the next repository. This behavior could allow an attacker to disrupt the service of a repository and leverage another repository to serve malicious artifacts. This attack requires the attacker to have control over a repository after the disrupted repository. Gradle has introduced a change in behavior in Gradle 9.3.0 to stop searching other repositories when encountering these errors.

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.

Latest version: 9.7.1

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.

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

Develocity (formerly Gradle Enterprise) before 2024.3.1 allows an attacker who has network access to a Develocity server to obtain the hashed password of the system user. The hash algorithm used by Develocity was chosen according to best practices for password storage and provides some protection against brute-force attempts. The applicable severity of this vulnerability depends on whether a Develocity server is accessible by external or unauthorized users, and the complexity of the System User password.

Impact

This vulnerability impacts GitHub workflows using the Gradle Build Action 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, you should delete any potentially vulnerable cache entries and may choose to rotate any potentially affected secrets (see Remediation).

Patches

Gradle Build Action v2.4.2 (and newer) no longer save this sensitive data for later use, preventing ongoing leakage of secrets via the GitHub Actions Cache. We strongly recommend that all users of the Gradle Build Action upgrade to v2.4.2 (or simply v2) immediately.

Remediation

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-. We recommend that users of the Gradle Build Action inspect their list of cache entries and manually delete any that match this pattern.

While we have not seen any evidence of this vulnerability being exploited, we recommend cycling any repository secrets if you cannot be certain that these have not been compromised. Compromise could occur if you run 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.

Workarounds

We strongly recommend that all users upgrade to the latest version of the Gradle Build Action as soon as possible, and delete any potentially vulnerable cache entries from the GitHub Actions cache (see Remediation).

If for some reason this is not possible, users can limit the impact of this vulnerability: - 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, as described here.

Develocity (formerly Gradle Enterprise) before 2024.1.8 has Incorrect Access Control. Project-level access control configuration was introduced in Enterprise Config schema version 8. Migration functionality from schema version 8 to versions 9 and 10 (in affected vulnerable versions) does not include the projects section of the configuration. This leads to all of the project settings being reset to their defaults when the old schema is loaded. In the case of projects.enabled, the default is false. Thus, using an enterprise config v8 results in Project level access control being disabled, even if it was previously enabled, and previously restricted project information disclosed. Most commonly, this occurs when a Develocity instance is upgraded from an earlier version. Specifically, this occurs if: Develocity 2023.3.X is upgraded to 2023.4.X; Develocity 2023.3.X is upgraded to 2024.1.X up to and including 2024.1.7; or Develocity 2023.4.X is upgraded to 2024.1.X up to and including 2024.1.7. The flaw does not occur when upgrading to a fixed version. An upgrade can only be triggered via administrator access, and cannot be forced by an external attacker.

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.

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.

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.

End of support: 7/31/2025, Latest version: 8.14.5

End of support: 7/31/2025, Latest version: 8.14.5