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:
<project-root>/.gradle directories.Some workarounds to limit the impact of this vulnerability are available:
--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.
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Build_action | Gradle | * | 2.4.2 (excluding) |
There are many different kinds of mistakes that introduce information exposures. The severity of the error can range widely, depending on the context in which the product operates, the type of sensitive information that is revealed, and the benefits it may provide to an attacker. Some kinds of sensitive information include:
Information might be sensitive to different parties, each of which may have their own expectations for whether the information should be protected. These parties include:
Information exposures can occur in different ways:
It is common practice to describe any loss of confidentiality as an “information exposure,” but this can lead to overuse of CWE-200 in CWE mapping. From the CWE perspective, loss of confidentiality is a technical impact that can arise from dozens of different weaknesses, such as insecure file permissions or out-of-bounds read. CWE-200 and its lower-level descendants are intended to cover the mistakes that occur in behaviors that explicitly manage, store, transfer, or cleanse sensitive information.