CVE-2026-116248 in pgAdmin
Summary
by MITRE • 10/30/2026
In pgAdmin 4 server mode only administrators are meant to share a server with all users; the server dialog shows the Shared switch only to them. The create and update endpoints of the server API, however, stored the "shared" flag and shared username they were sent, so any user able to register a server could share one with every other user. The servers.json import had a similar gap: a non-administrator's "Shared" entries were removed only after validation, so a file that also held an invalid entry could create a shared server.
A shared server carries no credentials, so this gives no direct access. It lets a user plant a server, named to look trusted, in every other user's tree and pointing at a host the user controls; anyone who then connects to it presents their own database password to that host.
The fix refuses a non-administrator's request that would share a server with HTTP 403, prunes a non-administrator's shared entries from a servers.json import before validating it, and warns at startup about servers shared earlier by non-administrators.
This issue affects pgAdmin 4: before 9.19.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/31/2026
The vulnerability in pgAdmin 4 prior to version 9.19 represents a critical authorization bypass within the server management subsystem, specifically affecting environments operating in server mode where multiple users interact with a central database administration interface. The core architectural flaw lies in an inconsistency between the user interface enforcement and the backend API logic regarding resource sharing permissions. While the graphical user interface correctly restricts visibility of the Shared switch to administrators only, ensuring that non-administrative users cannot visually opt into sharing configurations through standard interactions, this frontend control is not mirrored by sufficient server-side validation during data persistence operations. The application relies heavily on client-side restrictions for access control in certain areas, which fails when direct API calls or file imports bypass the UI layer entirely.
The technical root cause involves two distinct attack vectors within the server configuration endpoints. First, the create and update APIs for servers accept a shared flag and associated username parameters from any authenticated user without verifying whether that user holds administrative privileges. Consequently, an attacker with standard read-write access to their own database connections can craft API requests to mark specific server configurations as globally shared. This allows them to inject entries into the global configuration space intended exclusively for administrator-managed resources. Second, a similar logic gap exists in the servers.json import functionality used for bulk configuration management. Although the system attempts to strip non-administrator shared entries from imported files, this pruning operation occurs after validation rather than before. If an attacker submits an import file containing both invalid and valid server definitions, the presence of any error may cause the entire process or specific filtering steps to fail silently or partially succeed, leaving behind maliciously crafted shared entries that were not properly sanitized due to the flawed order of operations in the data processing pipeline.
The operational impact of this vulnerability is significant despite the absence of direct credential theft through the initial exploit mechanism. A shared server configuration does not store database passwords; instead, it acts as a pointer or alias for connection details such as hostnames and ports. By exploiting this flaw, an attacker can plant a maliciously named server entry into every other user's interface tree. The name is chosen to appear legitimate and trusted, potentially mimicking internal production databases or common service endpoints. When unsuspecting administrators or developers navigate their pgAdmin interface and attempt to connect to these planted entries, the client application prompts them for authentication credentials. Because the connection target points to a host controlled by the attacker, any password entered by the victim is transmitted directly to the malicious server rather than the intended database infrastructure. This facilitates credential harvesting through social engineering disguised as routine administrative tasks, effectively turning the administration tool into an attack vector against its own users.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-732 Incorrect Permission Assignment for Critical Resource, as it involves granting elevated sharing capabilities to unauthorized actors through insufficient access control checks on API endpoints. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts, where an attacker uses legitimate credentials to gain persistence and influence within a system, and potentially T1556 Modification of Authentication Process if the harvested credentials are used for lateral movement or further privilege escalation. The attack chain relies on the trust users place in their administration tools, making it particularly dangerous in enterprise environments where pgAdmin is widely deployed as the primary interface for PostgreSQL management.
To mitigate this risk and prevent similar issues in future development, strict server-side authorization checks must be implemented for all API endpoints that modify shared resource configurations. The create and update operations should explicitly verify that the requesting user possesses administrative roles before processing any requests to set a server as globally shared. For file import functionalities like servers.json parsing, validation logic must ensure that non-administrator users are strictly prohibited from defining shared entries at the data ingestion stage, prior to any error handling or filtering routines. Additionally, implementing robust input sanitization and role-based access control (RBAC) enforcement across all configuration mutation points is essential. Organizations running affected versions should immediately upgrade to pgAdmin 4 version 9.19 or later, which addresses these gaps by rejecting unauthorized sharing requests with appropriate HTTP status codes such as 403 Forbidden and correcting the import validation sequence. Furthermore, administrators should audit existing server configurations for any anomalous shared entries that may have been planted prior to patching and remove them manually if necessary.