WaratekVRT Sign in
Reset
More filters (1)
Columns
Including CVEs outside Waratek scope✕Product gradle✕
Overview 13 matches · 7 in Waratek scope · 1 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
13matches 7in Waratek scope53.8% 1protected7.7% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 1 7.7% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 6 46.2% Outside Waratek scope 0 0.0% Not applicable 6 46.2% Withdrawn CVE 0 0.0%
Critical 0 0.0% High 0 0.0% Medium 13 100.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 1 7.7% partly blocked 0 0.0% not blocked 12 92.3% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 2 15.4% Forecast only 0 0.0% No public exploit 11 84.6%
split by peak 4 / year
Not applicable: 6No exploit published: 6Protected by Waratek: 1 Medium: 13 not blocked: 12blocked by ARMR today: 1 No public exploit: 11Proof of concept only: 2
20192 No exploit published1 Not applicable1 Medium2 not blocked2 No public exploit2 20201 No exploit published1 Medium1 not blocked1 No public exploit1 20213 No exploit published3 Medium3 not blocked3 No public exploit3 20222 Not applicable2 Medium2 not blocked2 Proof of concept only1 No public exploit1 20234 No exploit published1 Not applicable3 Medium4 not blocked4 No public exploit4 20240 20250 20261 Protected by Waratek1 Medium1 blocked by ARMR today1 Proof of concept only1
20192020202120222023202420252026
13 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-75598 Medium 2026-11-06 Protected by Waratek Proof of concept only The Gradle Shadow plugin creates fat or uber JARs and supports file transformation and package relocation. Prior to version 9.6.0, Shadow does not independently validate ZIP entry names before writing them to its output archive. A malicious dependency can cause traversal entry names to be preserved when the applicable archive-processing path does not reject them. Some affected Shadow implementations process dependency archives directly, so upgrading Gradle alone does not universally prevent this behavior. If the resulting archive is extracted without path traversal protection, attacker-controlled files can be written outside the intended destination. This issue is fixed in version 9.6.0.
CVE-2023-42445 Medium 2023-10-06 Not applicable No public exploit Gradle is a build tool with a focus on build automation and support for multi-language development. In some cases, when Gradle parses XML files, resolving XML external entities is not disabled. Combined with an Out Of Band XXE attack (OOB-XXE), just parsing XML can lead to exfiltration of local text files to a remote server. Gradle parses XML files for several purposes. Most of the time, Gradle parses XML files it generated or were already present locally. Only Ivy XML descriptors and Maven POM files can be fetched from remote repositories and parsed by Gradle. In Gradle 7.6.3 and 8.4, resolving XML external entities has been disabled for all use cases to protect against this vulnerability. Gradle will now refuse to parse XML files that have XML external entities.
CVE-2023-44387 Medium 2023-10-05 Not applicable No public exploit Gradle is a build tool with a focus on build automation and support for multi-language development. When copying or archiving symlinked files, Gradle resolves them but applies the permissions of the symlink itself instead of the permissions of the linked file to the resulting file. This leads to files having too much permissions given that symlinks usually are world readable and writeable. While it is unlikely this results in a direct vulnerability for the impacted build, it may open up attack vectors depending on where build artifacts end up being copied to or un-archived. In versions 7.6.3, 8.4 and above, Gradle will now properly use the permissions of the file pointed at by the symlink to set permissions of the copied or archived file.
CVE-2023-39152 Medium 2023-07-26 No exploit published No public exploit Always-incorrect control flow implementation in Jenkins Gradle Plugin 2.8 may result in credentials not being masked (i.e., replaced with asterisks) in the build log in some circumstances.
CVE-2023-35946 Medium 2023-06-30 Not applicable No public exploit Gradle is a build tool with a focus on build automation and support for multi-language development. When Gradle writes a dependency into its dependency cache, it uses the dependency's coordinates to compute a file location. With specially crafted dependency coordinates, Gradle can be made to write files into an unintended location. The file may be written outside the dependency cache or over another file in the dependency cache. This vulnerability could be used to poison the dependency cache or overwrite important files elsewhere on the filesystem where the Gradle process has write permissions. Exploiting this vulnerability requires an attacker to have control over a dependency repository used by the Gradle build or have the ability to modify the build's configuration. It is unlikely that this would go unnoticed. A fix has been released in Gradle 7.6.2 and 8.2 to protect against this vulnerability. Gradle will refuse to cache dependencies that have path traversal elements in their dependency coordinates. It is recommended that users upgrade to a patched version. If you are unable to upgrade to Gradle 7.6.2 or 8.2, `dependency verification` will make this vulnerability more difficult to exploit.
CVE-2022-22984 Medium 2022-11-30 Not applicable Proof of concept only The package snyk before 1.1064.0; the package snyk-mvn-plugin before 2.31.3; the package snyk-gradle-plugin before 3.24.5; the package @snyk/snyk-cocoapods-plugin before 2.5.3; the package snyk-sbt-plugin before 2.16.2; the package snyk-python-plugin before 1.24.2; the package snyk-docker-plugin before 5.6.5; the package @snyk/snyk-hex-plugin before 1.1.6 are vulnerable to Command Injection due to an incomplete fix for [CVE-2022-40764](https://security.snyk.io/vuln/SNYK-JS-SNYK-3037342). A successful exploit allows attackers to run arbitrary commands on the host system where the Snyk CLI is installed by passing in crafted command line flags. In order to exploit this vulnerability, a user would have to execute the snyk test command on untrusted files. In most cases, an attacker positioned to control the command line arguments to the Snyk CLI would already be positioned to execute arbitrary commands. However, this could be abused in specific scenarios, such as continuous integration pipelines, where developers can control the arguments passed to the Snyk CLI to leverage this component as part of a wider attack against an integration/build pipeline. This issue has been addressed in the latest Snyk Docker images available at https://hub.docker.com/r/snyk/snyk as of 2022-11-29. Images downloaded and built prior to that date should be updated. The issue has also been addressed in the Snyk TeamCity CI/CD plugin as of version v20221130.093605.
CVE-2022-31156 Medium 2022-07-14 Not applicable No public exploit Gradle is a build tool. Dependency verification is a security feature in Gradle Build Tool that was introduced to allow validation of external dependencies either through their checksum or cryptographic signatures. In versions 6.2 through 7.4.2, there are some cases in which Gradle may skip that verification and accept a dependency that would otherwise fail the build as an untrusted external artifact. This can occur in two ways. When signature verification is disabled but the verification metadata contains entries for dependencies that only have a `gpg` element but no `checksum` element. When signature verification is enabled, the verification metadata contains entries for dependencies with a `gpg` element but there is no signature file on the remote repository. In both cases, the verification will accept the dependency, skipping signature verification and not complaining that the dependency has no checksum entry. For builds that are vulnerable, there are two risks. Gradle could download a malicious binary from a repository outside your organization due to name squatting. For those still using HTTP only and not HTTPS for downloading dependencies, the build could download a malicious library instead of the expected one. Gradle 7.5 patches this issue by making sure to run checksum verification if signature verification cannot be completed, whatever the reason. Two workarounds are available: Remove all `gpg` elements from dependency verification metadata if you disable signature validation and/or avoid adding `gpg` entries for dependencies that do not have signature files.
CVE-2021-25959 Medium 2021-09-29 No exploit published No public exploit In OpenCRX, versions v4.0.0 through v5.1.0 are vulnerable to reflected Cross-site Scripting (XSS), due to unsanitized parameters in the password reset functionality. This allows execution of external javascript files on any user of the openCRX instance.
CVE-2021-29429 Medium 2021-04-12 No exploit published No public exploit In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the `TextResourceFactory` API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only.
CVE-2021-21361 Medium 2021-03-09 No exploit published No public exploit The `com.bmuschko:gradle-vagrant-plugin` Gradle plugin contains an information disclosure vulnerability due to the logging of the system environment variables. When this Gradle plugin is executed in public CI/CD, this can lead to sensitive credentials being exposed to malicious actors. This is fixed in version 3.0.0.
CVE-2020-7599 Medium 2020-03-30 No exploit published No public exploit All versions of com.gradle.plugin-publish before 0.11.0 are vulnerable to Insertion of Sensitive Information into Log File. When a plugin author publishes a Gradle plugin while running Gradle with the --info log level flag, the Gradle Logger logs an AWS pre-signed URL. If this build log is publicly visible (as it is in many popular public CI systems like TravisCI) this AWS pre-signed URL would allow a malicious actor to replace a recently uploaded plugin with their own.
CVE-2019-16370 Medium 2019-09-16 No exploit published No public exploit The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.
CVE-2019-11065 Medium 2019-04-10 Not applicable No public exploit Gradle versions from 1.4 to 5.3.1 use an insecure HTTP URL to download dependencies when the built-in JavaScript or CoffeeScript Gradle plugins are used. Dependency artifacts could have been maliciously compromised by a MITM attack against the ajax.googleapis.com web site.