CVE-2026-116247 in pgAdmin
Summary
by MITRE • 10/30/2026
When a server in pgAdmin 4 had no password file, client certificate or client key configured, or the configured one could not be found, pgAdmin left the parameter out of the connection and libpq fell back to the defaults of the operating-system account running pgAdmin: ~/.pgpass, ~/.postgresql/postgresql.crt and postgresql.key, or PGPASSFILE, PGSSLCERT and PGSSLKEY. In server mode any user could therefore connect to a server with the service account's saved passwords or client certificate, and supplying only a copy of its public certificate was enough for libpq to pair it with the service account's private key. A pg_service.conf entry, or a maintenance database name read as a connection string by pg_dumpall, could bring the same files back for the utilities.
The fix gives each of these parameters a value in server mode, the user's own file or otherwise a path that can never be opened, in the connection string, in the environment of the utilities and in the --dbname connection string that ranks above a service entry. Desktop mode is unchanged.
This issue affects pgAdmin 4: before 9.19.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in versions of pgAdmin 4 prior to release 9.19 represents a critical authentication bypass and credential exposure flaw rooted in the application's handling of PostgreSQL connection parameters, specifically those related to Transport Layer Security (TLS) and password management. The core technical deficiency lies in how pgAdmin constructs database connections when specific security configurations are missing or invalid on the server side. Under normal secure operations, an administrator would explicitly configure client certificates and keys to enforce mutual TLS authentication. However, if these parameters were left unconfigured, marked as non-existent, or pointed to files that could not be located by the operating system, pgAdmin 4 exhibited a dangerous fallback behavior. Instead of rejecting the connection attempt due to missing security prerequisites, the application omitted these specific SSL and password-related parameters from the underlying libpq connection string entirely.
This omission triggers a default resolution mechanism within the PostgreSQL client library, libpq, which then falls back to system-level defaults determined by environment variables or standard file paths associated with the operating-system account running the pgAdmin service process. Specifically, libpq will attempt to read credentials and certificates from locations such as ~/.pgpass for passwords, ~/.postgresql/postgresql.crt for public certificates, and postgresql.key for private keys. Alternatively, it relies on explicit environment variables like PGPASSFILE, PGSSLCERT, and PGSSLKEY if they are set within the service account's context. This behavior fundamentally shifts the security boundary from the application layer to the operating system user identity hosting pgAdmin, creating a significant trust assumption that is often invalid in multi-tenant or shared server environments.
The operational impact of this vulnerability is severe, particularly when pgAdmin 4 is deployed in server mode where it acts as an intermediary for multiple users connecting to various database instances. An attacker with access to the web interface could exploit this flaw by configuring a target server entry without specifying client certificates or keys. Because pgAdmin omits these parameters from the connection string sent to libpq, the library utilizes the service account's stored credentials and private keys. Consequently, any authenticated user of the pgAdmin instance can connect to external PostgreSQL servers using the privileges and identity of the underlying system service account rather than their own individual permissions. This effectively grants lateral movement capabilities across database infrastructure that should be isolated by application-level authentication controls.
Furthermore, the vulnerability extends beyond simple connection manipulation through the web interface. The flaw impacts utility functions integrated within pgAdmin, such as those invoked during backup or maintenance operations. For instance, if a user specifies a service name via a pg_service.conf entry or provides a database name that is interpreted as a connection string by utilities like pg_dumpall, these tools inherit the same environment context and fallback behaviors. This allows an attacker to trigger background processes that read sensitive files from the service account's home directory, potentially exfiltrating private keys or password hashes stored in plaintext within .pgpass files. The requirement for exploitation is minimal; supplying only a copy of the public certificate associated with the service account was sufficient for libpq to pair it with the hidden private key located on disk, thereby completing the mutual TLS handshake without requiring knowledge of the actual secret material.
This issue aligns closely with CWE-256, which covers the storage of passwords in an insecure manner, and CWE-798, concerning the use of hardcoded or default credentials that provide unauthorized access. From a threat modeling perspective utilizing the MITRE ATT&CK framework, this vulnerability facilitates Initial Access through credential reuse and lateral movement via valid system accounts. It also relates to Discovery techniques where attackers probe for accessible services using stolen identities. The lack of explicit parameter enforcement allows an attacker to bypass intended authentication mechanisms by leveraging the host environment's trust relationships rather than authenticating as themselves.
The remediation strategy implemented in pgAdmin 4 version 9.19 addresses this flaw by enforcing strict parameterization regardless of configuration state. In server mode, the application now explicitly sets values for all SSL and password-related parameters within the connection string passed to libpq. If a user has not configured their own specific files, the system assigns paths that are guaranteed to be inaccessible or empty, thereby preventing any fallback to default locations like ~/.pgpass or ~/.postgresql/postgresql.crt. This ensures that connections do not inadvertently inherit credentials from the service account's environment. Additionally, for utility operations and maintenance database names processed as connection strings, similar strict parameterization is applied to prevent credential leakage through background processes. It is important to note that this fix applies specifically to server mode deployments; desktop mode installations remain unchanged in their behavior, relying on local user profiles which are generally more isolated from service-level risks but still require careful management of local file permissions and environment variables by the end-user administrator.