CVE-2026-120066 in psqlODBC
Summary
by MITRE • 11/02/2026
On Unix-like systems, when logging is enabled, psqlODBC creates its log files in /tmp by default, named from the program name, user name, and process ID, with the default permissions, typically world-readable, and follows symbolic links when opening them. A local user can read query text and data from another user's logs, and can place a symbolic link at the predictable path so that the driver appends log data to a file of the attacker's choosing with the victim's privileges. Versions before psqlODBC 18.00.0006 are affected.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability in psqlODBC prior to version 18.00.0006 stems from insecure handling of log file creation and management on Unix-like operating systems, specifically involving predictable file paths and insufficient permission controls. When the logging feature is enabled within the driver, it defaults to writing diagnostic information into the /tmp directory. The filenames generated for these logs are constructed using a combination of the program name, the executing user's username, and the process identifier. This construction method results in highly predictable file names that can be easily anticipated by any local user on the system. Furthermore, the driver does not enforce restrictive permissions upon creating these files, leaving them with default world-readable settings. This configuration allows any authenticated local user to inspect the contents of another user's log files without requiring elevated privileges or exploiting a separate privilege escalation vector.
The operational impact of this flaw is twofold, encompassing both information disclosure and potential arbitrary file write capabilities through symlink attacks. First, because the logs are world-readable, an attacker can directly read sensitive data contained within them. These logs typically capture query text executed by the application using psqlODBC, which may include unencrypted passwords, personally identifiable information, financial records, or other confidential business logic embedded in SQL statements. This constitutes a significant breach of confidentiality and violates principles outlined under CWE-200, which covers exposure of sensitive information to unauthorized actors. The ability to harvest this data facilitates further reconnaissance and potential downstream attacks against the database backend or connected applications.
Secondly, the vulnerability extends beyond passive reading due to the driver's behavior regarding symbolic links. When opening log files for appending, psqlODBC follows symbolic links rather than creating new regular files exclusively. An attacker can exploit this by pre-creating a symbolic link at one of the predictable paths in /tmp that points to an arbitrary file on the filesystem owned or writable by the victim user running the database client application. When the vulnerable version of psqlODBC executes and attempts to write its log entry, it will follow the symlink and append data to the target file instead of a new log file. This mechanism allows for an arbitrary append vulnerability where the attacker can inject content into files with the privileges of the victim process. While this is primarily an integrity issue affecting specific configuration files or scripts that might be sourced later, it represents a serious security flaw categorized under CWE-59, which describes improper link resolution before use, commonly known as symlink following vulnerabilities.
This behavior aligns with attack patterns observed in the MITRE ATT&CK framework, particularly those involving local privilege escalation through file system manipulation and data exfiltration via insecure temporary file handling. The reliance on /tmp for sensitive logging is a common anti-pattern that fails to account for multi-user environments where isolation between processes is critical. The combination of predictable naming conventions and lack of atomic file creation or exclusive lock mechanisms creates an environment ripe for race conditions and symlink attacks, which are well-documented techniques in local exploitation scenarios.
To mitigate this vulnerability, organizations must upgrade psqlODBC to version 18.00.0006 or later, where these issues have been addressed by implementing more secure file creation practices such as using O_EXCL flags to prevent symlink following and enforcing restrictive umask settings for log files. In the interim, administrators should disable logging if it is not strictly required for operational purposes. If logging must remain enabled, logs should be redirected to a directory with restricted permissions that are only accessible by the specific service account running the application, rather than relying on shared directories like /tmp. Additionally, implementing strict umask policies at the system level can help ensure that newly created files do not inherit world-readable permissions, thereby reducing the window of exposure for information disclosure attacks until the software patch is applied.