Filtered by vendor Gradle
Subscriptions
Total
47 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2021-41619 | 1 Gradle | 1 Enterprise | 2024-08-04 | 7.2 High |
| 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. | ||||
| CVE-2021-41586 | 1 Gradle | 1 Gradle | 2024-08-04 | 7.5 High |
| In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks can potentially reset the system user password. | ||||
| CVE-2021-41587 | 1 Gradle | 1 Gradle | 2024-08-04 | 7.5 High |
| In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks can potentially discover credentials for other resources. | ||||
| CVE-2021-41590 | 1 Gradle | 1 Enterprise | 2024-08-04 | 5.3 Medium |
| 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. | ||||
| CVE-2021-41584 | 1 Gradle | 1 Gradle | 2024-08-04 | 7.5 High |
| 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. | ||||
| CVE-2021-41588 | 1 Gradle | 1 Gradle | 2024-08-04 | 8.1 High |
| 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. | ||||
| CVE-2021-41589 | 1 Gradle | 2 Build Cache Node, Enterprise | 2024-08-04 | 9.8 Critical |
| 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. | ||||
| CVE-2021-32751 | 1 Gradle | 1 Gradle | 2024-08-03 | 7.5 High |
| 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. | ||||
| CVE-2021-29429 | 3 Gradle, Quarkus, Redhat | 4 Gradle, Quarkus, Camel Quarkus and 1 more | 2024-08-03 | 4 Medium |
| 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-29428 | 3 Gradle, Quarkus, Redhat | 3 Gradle, Quarkus, Quarkus | 2024-08-03 | 8.8 High |
| 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. | ||||
| CVE-2021-29427 | 3 Gradle, Quarkus, Redhat | 3 Gradle, Quarkus, Quarkus | 2024-08-03 | 8 High |
| 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. | ||||
| CVE-2021-26719 | 1 Gradle | 3 Enterprise Test Distribution Agent, Maven, Test Distribution | 2024-08-03 | 6.5 Medium |
| 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. | ||||
| CVE-2022-41574 | 1 Gradle | 1 Enterprise | 2024-08-03 | 7.5 High |
| 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. | ||||
| CVE-2022-41575 | 1 Gradle | 1 Enterprise | 2024-08-03 | 7.5 High |
| 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. | ||||
| CVE-2022-31156 | 1 Gradle | 1 Gradle | 2024-08-03 | 6.6 Medium |
| 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-2022-30586 | 1 Gradle | 1 Gradle | 2024-08-03 | 7.2 High |
| Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to code execution. | ||||
| CVE-2022-30587 | 1 Gradle | 1 Gradle Enterprise | 2024-08-03 | 7.5 High |
| Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to information disclosure. | ||||
| CVE-2022-27919 | 1 Gradle | 1 Enterprise | 2024-08-03 | 9.8 Critical |
| 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. | ||||
| CVE-2022-27225 | 1 Gradle | 1 Enterprise | 2024-08-03 | 6.5 Medium |
| 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. | ||||
| CVE-2022-25364 | 1 Gradle | 1 Enterprise | 2024-08-03 | 8.1 High |
| 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.) | ||||