Temp directory permission issue in Guava
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 32.0, 32.0.0-android
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
A temp directory creation vulnerability exists in all versions of Guava, allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava API com.google.common.io.Files.createTempDir(). By default, on unix-like systems, the created directory is world-readable (readable by an attacker with access to the system). The method in question has been marked @Deprecated in versions 30.0 and later and should not be used. For Android developers, we recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime's java.io.tmpdir system property to point to a location whose permissions are appropriately configured.
Timeline
- CVE published
- Record last updated
Affected versions
- Google LLC Guava
From 1.0 · fixed in 32.0
- com.google.guava:guavaMaven
fixed in 32.0.0-android
References 25
GitHub · google/guava
lists.apache.org
- thread.html/r68d86f4b06c808204f62bcb254fcb5b0432528ee8d37a07ef4bc8222@<commits.ws.apache.org>
- thread.html/r215b3d50f56faeb2f9383505f3e62faa9f549bb23e8a9848b78a968e@<commits.ws.apache.org>
- thread.html/rb8c0f1b7589864396690fe42a91a71dea9412e86eec66dc85bbacaaf@<commits.cxf.apache.org>
- thread.html/r4776f62dfae4a0006658542f43034a7fc199350e35a66d4e18164ee6@<commits.cxf.apache.org>
- thread.html/rbc7642b9800249553f13457e46b813bea1aec99d2bc9106510e00ff3@<torque-dev.db.apache.org>
- thread.html/r841c5e14e1b55281523ebcde661ece00b38a0569e00ef5e12bd5f6ba@<issues.maven.apache.org>
- thread.html/rc2dbc4633a6eea1fcbce6831876cfa17b73759a98c65326d1896cb1a@<torque-dev.db.apache.org>
- thread.html/rd5d58088812cf8e677d99b07f73c654014c524c94e7fedbdee047604@<torque-dev.db.apache.org>
- thread.html/r3c3b33ee5bef0c67391d27a97cbfd89d44f328cf072b601b58d4e748@<commits.pulsar.apache.org>
- thread.html/rfc27e2727a20a574f39273e0432aa97486a332f9b3068f6ac1346594@<dev.myfaces.apache.org>
- thread.html/rd01f5ff0164c468ec7abc96ff7646cea3cce6378da2e4aa29c6bcb95@<github.arrow.apache.org>
- thread.html/r2fe45d96eea8434b91592ca08109118f6308d60f6d0e21d52438cfb4@<dev.drill.apache.org>
- thread.html/r07ed3e4417ad043a27bee7bb33322e9bfc7d7e6d1719b8e3dfd95c14@<dev.drill.apache.org>
- thread.html/r6874dfe26eefc41b7c9a5e4a0487846fc4accf8c78ff948b24a1104a@<dev.drill.apache.org>
- thread.html/r161b87f8037bbaff400194a63cd2016c9a69f5949f06dcc79beeab54@<dev.drill.apache.org>
- thread.html/ra7ab308481ee729f998691e8e3e02e93b1dedfc98f6b1cd3d86923b3@<yarn-issues.hadoop.apache.org>
- thread.html/rf00b688ffa620c990597f829ff85fdbba8bf73ee7bfb34783e1f0d4e@<yarn-dev.hadoop.apache.org>
- thread.html/r58a8775205ab1839dba43054b09a9ab3b25b423a4170b2413c4067ac@<common-issues.hadoop.apache.org>
- thread.html/re120f6b3d2f8222121080342c5801fdafca2f5188ceeb3b49c8a1d27@<yarn-issues.hadoop.apache.org>
- thread.html/r49549a8322f62cd3acfa4490d25bfba0be04f3f9ff4d14fe36199d27@<yarn-dev.hadoop.apache.org>