CVE-2026-116240 in pgAdmin 4
Summary
by MITRE • 10/30/2026
In server mode pgAdmin 4 validates a path into the user's storage directory with check_access_permission(), which builds the absolute path with get_abs_path(). Several callers then acted on a path they built differently, so the path checked and the path used could name different files:
- Opening a file in the Query Tool, the Google client secret and, on Windows, Import/Export Data, Backup, Restore and saving a file joined the path to the storage directory after stripping leading slashes and backslashes. On POSIX a path checked as a name inside storage could become an absolute path once stripped, so any file the pgAdmin account can read could be opened; on Windows a path naming a drive discarded the storage directory, so these could read, or write, outside it. - Listing a folder decoded the path a second time after the check, so a folder named like an encoded "..", which a user can create, listed any directory on the host. - Download, delete, rename and the file-exists check appended the path to the storage directory without a separator, so in a deployment where one user's storage directory name is a prefix of another's, another user's files could be read, deleted or moved; download also checked the path appended to itself. - Creating a folder could create one in another user's directory.
The fix makes check_access_permission() return the path it checked and every caller act on that path, decodes folder paths once, and opens, deletes and renames files relative to directories opened from the storage directory without following symbolic links. Desktop mode is not affected.
This issue affects pgAdmin 4: before 9.19.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability in pgAdmin 4 prior to version 9.19 represents a critical path traversal and authorization bypass flaw rooted in inconsistent handling of file system paths within the server mode application logic. The core technical defect lies in the disconnect between the validation mechanism, specifically the check_access_permission function which utilizes get_abs_path to construct an absolute path for security verification, and the subsequent operations performed by various callers that reconstruct or manipulate these paths differently. This architectural inconsistency means that the path subjected to permission checks is not necessarily the same path used for actual file system interactions, creating a classic time-of-check-to-time-of-use (TOCTOU) scenario where attackers can exploit discrepancies between validated permissions and executed actions.
In server mode, several distinct operational contexts expose different attack vectors due to this flaw. When opening files through the Query Tool or handling Google client secrets on Windows systems such as during Import/Export Data operations, Backup, Restore, or file saving processes, the application strips leading slashes and backslashes from user-supplied paths before joining them with the storage directory. On POSIX-compliant operating systems, stripping a leading slash can transform what was intended to be a relative path into an absolute path once processed by the underlying system calls. This allows an authenticated attacker to bypass access controls entirely, gaining read access to any file on the host that the pgAdmin process account has permissions to open. Similarly, on Windows environments, paths naming specific drives cause the storage directory prefix to be discarded during processing, enabling unauthorized reading or writing outside of the designated isolated storage area.
Further exploitation is possible through folder listing operations where path decoding occurs twice: once for permission validation and again after the check completes. An attacker can create a folder with a name that resembles an encoded parent directory reference, such as double-encoded dot-dot sequences. Because the second decode happens post-validation, this crafted input bypasses the initial security checks and results in the application listing the contents of arbitrary directories on the host system rather than restricting output to the user's designated storage location. This leakage provides attackers with valuable reconnaissance data regarding file structures and potentially sensitive information stored elsewhere on the server.
Additional risks arise from improper path concatenation during download, delete, rename, and existence check operations where paths are appended directly to the storage directory without inserting a separating delimiter. In deployments where one user's storage directory name serves as a prefix for another user’s directory, this lack of separation allows cross-user file access. For instance if User A has a storage path ending in characters that form the beginning of User B’s path, an attacker acting as User A can manipulate paths to target and read, delete, or move files belonging to User B. The download functionality exhibits an even more severe variant where the path is checked against itself appended to its own value, further widening the scope for unauthorized data exfiltration. Furthermore, folder creation operations suffer from similar logic errors that permit the creation of directories within other users' storage spaces, potentially facilitating persistent access or denial-of-service conditions by cluttering shared resources.
This vulnerability maps directly to CWE-22 Improper Limitation of a Pathname to a Restricted Directory and CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition in the Common Weakness Enumeration taxonomy. From an adversary perspective, these capabilities align with ATT&CK techniques involving File and Directory Discovery T1083 for reconnaissance and Unauthorized Access to Functionality or Data depending on whether read-only access is achieved versus write permissions being exploited. The impact ranges from severe information disclosure of sensitive configuration files and user data to potential remote code execution if writable paths allow injection of malicious scripts into executable locations, although the primary confirmed impacts are unauthorized file system access across tenant boundaries in multi-user deployments.
The remediation strategy implemented in pgAdmin 4 version 9.19 addresses these issues by enforcing strict consistency between validation and usage phases. The fix modifies check_access_permission to return the validated absolute path rather than just a boolean result, ensuring that every caller operates on the exact same path object that was subjected to security checks. Additionally, folder paths are decoded only once prior to any further processing to prevent double-decoding attacks. File operations such as opening, deleting, and renaming now utilize relative paths derived from directories opened directly within the storage root without following symbolic links, thereby neutralizing absolute path injection techniques on POSIX systems and drive letter exploits on Windows. Desktop mode remains unaffected by these specific server-side logic errors due to its different execution context and isolation model. Organizations running affected versions must upgrade immediately to mitigate risks of data leakage and privilege escalation across user accounts in shared pgAdmin deployments.