Insecure Temporary File Affecting gradle package, versions <4.4.1-150200.3.15.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.48% (38th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-SLES153-GRADLE-6591915
  • published8 Apr 2024
  • disclosed5 Apr 2024

Introduced: 5 Apr 2024

CVE-2021-29429  (opens in a new tab)
CWE-377  (opens in a new tab)

How to fix?

Upgrade SLES:15.3 gradle to version 4.4.1-150200.3.15.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream gradle package and not the gradle package as distributed by SLES. See How to fix? for SLES:15.3 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1