CVE-2026-116245 in pgAdmin
Summary
by MITRE • 10/30/2026
libpq looks a connection service up in the service file of the operating-system account running pgAdmin 4, and an entry there can hold a password or name a password file or client certificate. In server mode any user could set a server's Service, or a "service" connection parameter, to one of those entries and connect with its credentials. A PGPASSWORD or PGSERVICE variable set for that account was likewise used by libpq for every connection without a value of its own and passed on to the utilities, and pg_dumpall read a maintenance database name such as "service=..." as a connection string.
The fix adds the SERVER_MODE_ALLOWED_SERVICES setting, empty by default: in server mode only a listed service can be used, the servicefile parameter is refused, and PGPASSWORD and PGSERVICE are removed from pgAdmin's environment at startup. The allowlist is checked again on the final connection string, and the pg_dumpall database name is wrapped as a connection string.
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/31/2026
The vulnerability identified in versions of pgAdmin 4 prior to 9.19 stems from an insecure handling of PostgreSQL client library configuration parameters, specifically within the server mode deployment context. The core technical flaw lies in how libpq, the underlying C client library for PostgreSQL connections utilized by pgAdmin, resolves connection services. When operating in server mode, which is typical for multi-user deployments where a central web application serves multiple clients, any authenticated user could manipulate the SERVER_NAME or SERVICE connection parameters to reference entries defined in the system-level service file associated with the account running the pgAdmin process. This configuration mechanism allows an entry to specify credentials directly via embedded passwords, point to external password files containing sensitive secrets, or define client certificates for authentication. Consequently, a malicious actor who gains access to the application interface could force the backend connection pool to utilize these pre-configured services, thereby bypassing intended authentication controls and connecting with elevated privileges or accessing databases that should remain isolated from their user context.
The operational impact of this vulnerability is severe as it effectively allows for privilege escalation and unauthorized data access across multiple database instances managed by a single pgAdmin server instance. By leveraging the PGSERVICE parameter or manipulating environment variables such as PGPASSWORD, an attacker can hijack connections intended for administrative maintenance tasks. The issue was further exacerbated because utilities like pg_dumpall incorrectly interpreted certain input strings, including those containing service specifications, as direct connection strings rather than validating them against safe patterns. This lack of strict validation meant that sensitive configuration details stored in the operating system account's environment or service files were inadvertently exposed to any user capable of submitting a crafted server name or database identifier. The attack vector primarily aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials, as it exploits trust relationships between application components and underlying OS-level configuration mechanisms without sufficient isolation boundaries.
To mitigate this risk, the remediation strategy implemented in version 9.19 introduces a strict allowlist mechanism governed by the SERVER_MODE_ALLOWED_SERVICES setting. By default, this list is empty, which effectively disables the use of system-defined service files unless explicitly permitted by an administrator for specific, trusted services. The fix also enforces stricter validation on connection parameters by refusing requests that attempt to set the SERVICEFILE parameter directly from user input. Furthermore, security hardening measures include stripping PGPASSWORD and PGSERVICE variables from the pgAdmin process environment at startup time, ensuring that these sensitive credentials cannot be inherited or leaked across different user sessions within the same application instance. The validation logic is reinforced by checking the allowlist again during the final connection string assembly phase to prevent bypass attempts through parameter manipulation. Additionally, inputs for database names in utilities like pg_dumpall are now wrapped and validated as proper connection strings rather than raw identifiers, closing the parsing loophole that previously allowed service injection.
From a threat modeling perspective, this vulnerability represents a classic case of insecure configuration management where application-level controls fail to isolate user input from system-level security contexts. It relates closely to ATT&CK technique T1078 Valid Accounts, as it allows an attacker to leverage valid but unintended credentials associated with the service account running the backend process. Defense in depth requires that administrators not only apply this software update but also review their pgAdmin deployment configurations to ensure that SERVER_MODE_ALLOWED_SERVICES is configured appropriately if any system services are required for legitimate operations. Regular auditing of environment variables and strict separation of privileges between application processes and database accounts remain critical practices to prevent similar exploitation vectors in future deployments.