Search for packages
| purl | pkg:maven/org.postgresql/postgresql@42.2.26.jre6 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-hpc5-vtmd-gub5
Aliases: CVE-2022-26520 GHSA-727h-hrw8-jg8q |
Path traversal in org.postgresql:postgresql ** DISPUTED ** In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties. |
Affected by 1 other vulnerability. |
|
VCID-qub7-qp14-uqcg
Aliases: CVE-2022-41946 GHSA-562r-vg33-8x8h |
TemporaryFolder on unix-like systems does not limit access to created files **Vulnerability** `PreparedStatement.setText(int, InputStream)` and `PreparedStatemet.setBytea(int, InputStream)` will create a temporary file if the InputStream is larger than 51k Example of vulnerable code: ```java String s = "some very large string greater than 51200 bytes"; PreparedStatement.setInputStream(1, new ByteArrayInputStream(s.getBytes()) ); ``` This will create a temporary file which is readable by other users on Unix like systems, but not MacOS. Impact On Unix like systems, the system's temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system. This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability. When analyzing the impact of this vulnerability, here are the important questions to ask: Is the driver running in an environment where the OS has other untrusted users. If yes, and you answered 'yes' to question 1, this vulnerability impacts you. If no, this vulnerability does not impact you. Patches Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using. Java 1.8 and higher users: this vulnerability is fixed in 42.2.27, 42.3.8, 42.4.3, 42.5.1 Java 1.7 users: this vulnerability is fixed in 42.2.27.jre7 Java 1.6 and lower users: no patch is available; you must use the workaround below. Workarounds If you are unable to patch, or are stuck running on Java 1.6, specifying the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability. References [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html) Fix commit https://github.com/pgjdbc/pgjdbc/commit/9008dc9aade6dbfe4efafcd6872ebc55f4699cf5 Similar Vulnerabilities Google Guava - https://github.com/google/guava/issues/4011 Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 |
Affected by 2 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-uzj4-puvz-zfgh
Aliases: GHSA-673j-qm5f-xpv8 GMS-2022-75 |
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control. It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system. While we do not consider this a security issue with the driver, we have decided to remove the `loggerFile` and `loggerLevel` connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to `java.util.logging`. |
Affected by 1 other vulnerability. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||