CVE-2026-116249 in pgAdmin
Summary
by MITRE • 10/30/2026
In server mode pgAdmin 4 resolves a server's password file, SSL certificate, key, CRL and SSH tunnel identity file relative to the user's storage directory, but get_complete_file_path() only stripped leading slashes before joining the two. A path such as "../<another user>/.pgpass", set through the server dialog, the REST API or a servers.json import, therefore named another user's file, and connecting used that user's saved passwords, client certificate or SSH key. The sslkeylogfile connection parameter was passed to libpq unchanged, so a path outside storage let libpq create or append a file as the account running pgAdmin.
make_conninfo() also quoted connection parameter values but not their names, so a crafted parameter name could smuggle additional keyword=value pairs past these checks.
The fix requires the resolved path, with symbolic links followed, to stay inside the user's storage directory or the named shared storage directory, confines sslkeylogfile the same way, and accepts only exact libpq keywords as connection parameter names. A refused path or keyword is reported instead of letting libpq fall back to a default.
This issue affects pgAdmin 4: before 9.19.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability in pgAdmin 4 prior to version 9.19 represents a critical failure in input validation and path resolution logic, specifically within the server configuration handling mechanisms. The core technical flaw lies in how the application resolves file paths for sensitive security assets such as password files, SSL certificates, private keys, Certificate Revocation Lists, and SSH tunnel identity files. When operating in server mode, pgAdmin 4 attempts to resolve these paths relative to a designated user storage directory or shared storage location. However, the implementation of the get_complete_file_path function is insufficiently robust; it merely strips leading slashes from provided path strings before concatenating them with the base storage directory. This naive approach fails to account for absolute paths that escape the intended sandbox or utilize traversal sequences effectively despite the stripping logic if not carefully constrained against all forms of relative navigation and symbolic link resolution.
This inadequate validation allows an attacker who can control server configuration inputs through the web interface, REST API, or by importing a servers.json file to specify arbitrary file locations on the underlying operating system. By constructing path strings that include directory traversal sequences such as double dots followed by slashes, an adversary can reference files outside the permitted storage boundaries. For instance, specifying a path like ..//.pgpass allows the application to resolve and read password credentials belonging to other users or system accounts stored in standard locations like /home/user/.pgpass or similar directories depending on the deployment environment. Consequently, when a connection is established using this compromised configuration, pgAdmin 4 utilizes these unauthorized credentials, effectively granting access to resources protected by passwords saved under different user contexts. This constitutes a severe information disclosure and privilege escalation vector, as it bypasses intended isolation between users within the same pgAdmin instance.
Beyond file path manipulation, the vulnerability extends to how connection parameters are processed via libpq, the PostgreSQL client library interface used by pgAdmin. The make_conninfo function correctly quotes parameter values but fails to adequately validate or restrict parameter names. This oversight permits a crafted parameter name that contains embedded keyword-value pairs to bypass validation checks. By smuggling additional configuration directives into the connection string through malformed keys, an attacker can potentially alter the behavior of the database connection in unintended ways. Furthermore, the sslkeylogfile connection parameter is passed directly to libpq without path restriction. If an external path is provided for this log file, libpq will create or append to that file with the privileges of the account running pgAdmin. This capability enables arbitrary file creation and modification on the server hosting pgAdmin, which can be leveraged for further exploitation such as writing malicious scripts into web-accessible directories or overwriting critical system configuration files if permissions allow.
The operational impact of these flaws is significant, affecting both confidentiality and integrity within multi-tenant deployments where multiple users share a single pgAdmin instance. An attacker with access to the server dialog or API can steal sensitive authentication material from other users, including SSH keys used for tunneling connections. This undermines the fundamental security model of role-based isolation intended by the application architecture. Additionally, the ability to write arbitrary files via sslkeylogfile introduces risks related to code execution and system compromise if the running account has sufficient permissions on the host filesystem. These issues collectively represent a breakdown in secure coding practices regarding path canonicalization and input sanitization, exposing organizations using pgAdmin 4 versions before 9.19 to substantial risk of unauthorized access and potential remote code execution depending on the deployment context.
To mitigate these vulnerabilities, it is imperative to upgrade immediately to pgAdmin version 9.19 or later, where the path resolution logic has been hardened. The fix ensures that resolved paths, after following symbolic links, remain strictly within the designated user storage directory or approved shared storage directories. This prevents any form of directory traversal from escaping the intended sandbox boundaries. Similarly, the sslkeylogfile parameter is now subject to the same strict confinement rules, ensuring it cannot be used to write files outside allowed locations. Furthermore, the application now enforces exact matching for libpq connection parameter names, rejecting any input that does not correspond to a valid keyword recognized by PostgreSQL's client library. This prevents the smuggling of additional parameters through malformed keys and ensures that only expected configuration options are processed. Organizations should also review their deployment configurations to ensure no legacy servers with vulnerable versions remain in production environments until they can be patched or decommissioned.