- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 12
- Public CVEs
- 50
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
12 assets you may test, 6 excluded.
Web 1
- https://gradle.org
Products and areas 11
- Build script compilation and evaluation for both the Groovy and Kotlin DSLs, plus init scripts, included builds and buildSrc
- Credential handling for repository authentication, together with anything that lands a secret in build output, a log or a build scan
- Dependency resolution and artefact download from Maven and Ivy repositories, including repository metadata handling, redirects and mirror behaviour
- Java toolchain provisioning, where Gradle downloads and installs a JDK on demand
- Plugin resolution from the Gradle Plugin Portal and the plugin marker mechanism behind it
- The build cache, local and remote, covering cache key derivation, entry packing and unpacking, and anything that lets one build's output be served to another build
- The configuration cache and the serialised state it stores and later replays
- The dependency verification subsystem in full: checksum and signature checking, the verification metadata file, key server lookups and trusted-key handling
- The Gradle daemon and everything reachable across its client connection, including the Tooling API that IDEs drive it through
- The Gradle wrapper: the checked-in wrapper JAR, the distribution download and the checksum verification meant to make that download safe
- The policy declares a wide scope in writing: the Gradle Build Tool, Develocity, the Build Cache node Docker image, the official plugins, and any non-example, non-archived repository in the Gradle GitHub org, along with the gradle.org, gradle.com and grdev.net domains. Third-party dependencies count too where you can show the impact on Gradle's own use of them. Reports go to [email protected]
Out of scope (6)
- A build executing code the build script legitimately asked it to execute, which is the entire job of a build tool
- Maven Central, the Plugin Portal and other registries as services, as opposed to Gradle's handling of what they return
- Reports filed on the HackerOne directory listing, which is an external entry with no live program behind it
- The Android Gradle Plugin, which is Google's code and goes through Google's process
- The JVM and the JDK themselves, which have their own vendors and their own reporting paths
- Third-party plugins published to the Plugin Portal, which belong to their authors; a plugin behaving badly is an ecosystem problem rather than a Gradle defect
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Email the address on the policy page . The policy asks for all security bug reports to go there
-
GitHub private vulnerability reporting is off on gradle/gradle , so the advisory button is not an option here even though it is the norm elsewhere in this category
-
Say which Gradle version and which JVM, and whether the build had the configuration cache, the build cache or dependency verification switched on.
-
Include the build script and the dependency declarations.
-
Android Gradle Plugin defects belong to Google and third-party plugins belong to their authors, both of which are different reporting paths
Not accepted
-
The Android Gradle Plugin, which is Google's code and goes through Google's process
-
Third-party plugins published to the Plugin Portal, which belong to their authors; a plugin behaving badly is an ecosystem problem rather than a Gradle defect
-
Maven Central, the Plugin Portal and other registries as services, as opposed to Gradle's handling of what they return
-
A build executing code the build script legitimately asked it to execute, which is the entire job of a build tool
-
The JVM and the JDK themselves, which have their own vendors and their own reporting paths
-
Reports filed on the HackerOne directory listing, which is an external entry with no live program behind it
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 9 minutes ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-25063 | 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 descripti | High 8.3 | 29 Jan 2026 |
| CVE-2026-22816 | 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 fr | High 8.6 | 16 Jan 2026 |
| CVE-2026-22865 | 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 fr | High 8.6 | 16 Jan 2026 |
| CVE-2023-49238 | 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. | Critical 9.8 | 9 Jan 2024 |
| CVE-2023-42445 | 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 pa | Medium 6.8 | 6 Oct 2023 |
| CVE-2023-44387 | 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 i | Low 3.2 | 5 Oct 2023 |
| CVE-2023-35946 | 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 anoth | Medium 6.9 | 30 Jun 2023 |
| CVE-2023-35947 | 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 co | Medium 6.9 | 30 Jun 2023 |
| CVE-2023-30853 | 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 Bu | High 7.6 | 28 Apr 2023 |
| CVE-2023-26053 | 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 f | Medium 6.6 | 2 Mar 2023 |
| CVE-2022-41575 | 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. | High 7.5 | 21 Oct 2022 |
| CVE-2022-41574 | 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. | High 7.5 | 7 Oct 2022 |
| CVE-2022-31156 | 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 artif | Medium 6.6 | 14 Jul 2022 |
| CVE-2022-30587 | Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to information disclosure. | High 7.5 | 6 Jun 2022 |
| CVE-2022-30586 | Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to code execution. | High 7.2 | 6 Jun 2022 |
| CVE-2022-27919 | 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. | Critical 9.8 | 25 Mar 2022 |
| CVE-2022-25364 | 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 c | High 8.1 | 17 Mar 2022 |
| CVE-2022-27225 | 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 cook | Medium 6.5 | 16 Mar 2022 |
| CVE-2022-23630 | 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 configuratio | High 7.5 | 10 Feb 2022 |
| CVE-2021-41589 | 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 defa | Critical 9.8 | 27 Oct 2021 |
| CVE-2021-41590 | 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 environ | Medium 5.3 | 27 Oct 2021 |
| CVE-2021-41619 | 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 ca | High 7.2 | 27 Oct 2021 |
| CVE-2021-41586 | In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks can potentially reset the system user password. | High 7.5 | 24 Sep 2021 |
| CVE-2021-41587 | In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks can potentially discover credentials for other resources. | High 7.5 | 24 Sep 2021 |
| CVE-2021-41588 | 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. | High 8.1 | 24 Sep 2021 |
| CVE-2021-41584 | 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. | High 7.5 | 24 Sep 2021 |
| CVE-2021-32751 | 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 | High 7.5 | 20 Jul 2021 |
| CVE-2021-29427 | 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, Gradl | High 8.0 | 13 Apr 2021 |
| CVE-2021-29428 | 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 | High 8.8 | 13 Apr 2021 |
| CVE-2021-29429 | 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 expos | Medium 4.0 | 12 Apr 2021 |
| CVE-2021-26719 | 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. | Medium 6.5 | 9 Feb 2021 |
| CVE-2020-11979 | 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. | High 7.5 | 1 Oct 2020 |
| CVE-2020-15773 | 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. | Medium 6.5 | 18 Sep 2020 |
| CVE-2020-15776 | 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. | High 8.8 | 18 Sep 2020 |
| CVE-2020-15767 | 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. | Medium 5.3 | 18 Sep 2020 |
| CVE-2020-15768 | 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 p | High 7.5 | 18 Sep 2020 |
| CVE-2020-15769 | An issue was discovered in Gradle Enterprise 2020.2 - 2020.2.4. An XSS issue exists via the request URL. | Medium 6.1 | 18 Sep 2020 |
| CVE-2020-15770 | 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. | Medium 5.5 | 18 Sep 2020 |
| CVE-2020-15771 | 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. | High 7.5 | 18 Sep 2020 |
| CVE-2020-15772 | 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. | Medium 4.9 | 18 Sep 2020 |
| CVE-2020-15774 | 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. | Medium 6.8 | 18 Sep 2020 |
| CVE-2020-15775 | 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. | High 7.5 | 18 Sep 2020 |
| CVE-2020-15777 | 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 r | High 7.8 | 25 Aug 2020 |
| CVE-2020-7599 | 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 all | Medium 6.5 | 30 Mar 2020 |
| CVE-2019-16370 | 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. | Medium 5.9 | 16 Sep 2019 |
| CVE-2019-15052 | 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. | Critical 9.8 | 14 Aug 2019 |
| CVE-2019-11403 | 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. | Critical 9.8 | 22 Apr 2019 |
| CVE-2019-11402 | In Gradle Enterprise before 2018.5.3, Build Cache Nodes did not store the credentials at rest in an encrypted format. | Critical 9.8 | 22 Apr 2019 |
| CVE-2019-11065 | 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. | Medium 5.9 | 10 Apr 2019 |
| CVE-2016-6199 | ObjectSocketWrapper.java in Gradle 2.12 allows remote attackers to execute arbitrary code via a crafted serialized object. | Critical 9.8 | 7 Feb 2017 |
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 5 Last 12 months Integrity bypass 35 % Cache poisoning 30 % Transport security 20 % Code execution 15 % Latest advisories Loading the feed Overview Gradle builds Android. Close to every app in the store is assembled by it, along with a large share of JVM server code, and it evaluates build scripts and resolves dependencies with the full privileges of the developer or the CI runner. The subsystem that decides whether this target matters is dependency verification: Gradle can be told to check checksums and signatures on everything it downloads, and a bypass of that check puts attacker-chosen bytes into every artefact built downstream. Gradle Inc. is a funded company and states in its policy that it offers no financial bug bounties, only swag, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy declares a wide scope in writing: the Gradle Build Tool, Develocity, the Build Cache node Docker image, the official plugins, and any non-example, non-archived repository in the Gradle GitHub org, along with the gradle.org , gradle.com and grdev.net domains. Third-party dependencies count too where you can show the impact on Gradle's own use of them. Reports go to [email protected] Dependency resolution and artefact download from Maven and Ivy repositories, including repository metadata handling, redirects and mirror behaviour The dependency verification subsystem in full: checksum and signature checking, the verification metadata file, key server lookups and trusted-key handling The build cache, local and remote, covering cache key derivation, entry packing and unpacking, and anything that lets one build's output be served to another build The configuration cache and the serialised state it stores and later replays The Gradle wrapper: the checked-in wrapper JAR, the distribution download and the checksum verification meant to make that download safe The Gradle daemon and everything reachable across its client connection, including the Tooling API that IDEs drive it through Build script compilation and evaluation for both the Groovy and Kotlin DSLs, plus init scripts, included builds and buildSrc Plugin resolution from the Gradle Plugin Portal and the plugin marker mechanism behind it Java toolchain provisioning, where Gradle downloads and installs a JDK on demand Credential handling for repository authentication, together with anything that lands a secret in build output, a log or a build scan Out of scope The Android Gradle Plugin, which is Google's code and goes through Google's process Third-party plugins published to the Plugin Portal, which belong to their authors; a plugin behaving badly is an ecosystem problem rather than a Gradle defect Maven Central, the Plugin Portal and other registries as services, as opposed to Gradle's handling of what they return A build executing code the build script legitimately asked it to execute, which is the entire job of a build tool The JVM and the JDK themselves, which have their own vendors and their own reporting paths Reports filed on the HackerOne directory listing, which is an external entry with no live program behind it Most-valued findings Dependency verification bypass: any path where an artefact that fails its checksum or signature is used anyway, or where verification silently does not apply to something a user believed it covered. This is the control the whole supply-chain story rests on Build cache poisoning, particularly against a remote cache shared across an organisation, where one write serves compiled output to every build that asks for the same key Cleartext or downgraded artefact resolution, and any place a checksum is trusted from the same source that served the artefact it is meant to validate Wrapper handling: swapping the distribution a gradlew invocation fetches, or getting past the verification on it, executes on every developer machine that clones the repository Plugin resolution confusion where a plugin id resolves to a coordinate the build did not intend Configuration cache or serialised state that carries an attacker-controlled value into a later build, and credential exposure through logs, build scans or cached entries Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Email [email protected] . The policy asks for all security bug reports to go there GitHub private vulnerability reporting is off on gradle/gradle , so the advisory button is not an option here even though it is the norm elsewhere in this category The stated thanks is swag for a previously unreported report that triggers a code or configuration change. There is no money to negotiate Say which Gradle version and which JVM, and whether the build had the configuration cache, the build cache or dependency verification switched on. Those subsystems carry the severe classes Include the build script and the dependency declarations. Findings here usually turn on what a build was told to resolve rather than on an exotic binary Android Gradle Plugin defects belong to Google and third-party plugins belong to their authors, both of which are different reporting paths Disclosure Coordinated by email with Gradle Inc., which fixes privately and ships the patch in a release. The policy publishes no response target and no fixed embargo length, so agree the timeline in the thread. Build tooling upgrades slowly inside enterprises and Android projects pin their Gradle version in the wrapper, so downstream needs real time before any writeup. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability