CVE-2026-116242 in pgAdmin
Summary
by MITRE • 10/30/2026
pgAdmin 4 opens SSH tunnels with the sshtunnel library but gave it neither host_pkey_directories nor ssh_config_file, so it always loaded the unencrypted private keys in ~/.ssh of the operating-system account running pgAdmin, read that account's ~/.ssh/config (IdentityFile, User, HostName, ProxyCommand) for the tunnel host, and could use its ssh-agent. In server mode any user could therefore configure a tunnel to a host that accepts the service account's key, with no credentials of their own or with an identity file that did not exist in their storage, and reach it as that account.
The fix makes tunnels in server mode use only the identity file or password the user configured: the service account's keys, configuration and agent are no longer used, and an identity file that cannot be found in the user's storage is reported instead of falling back to ~/.ssh. Desktop mode is unchanged.
This issue affects pgAdmin 4: before 9.19.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in pgAdmin 4 prior to version 9.19 represents a critical authentication bypass and privilege escalation flaw rooted in the improper configuration of SSH tunneling mechanisms within its server mode deployment architecture. The core technical deficiency lies in how the application initializes connections using the sshtunnel library, specifically regarding the handling of private keys and SSH client configurations. By failing to explicitly restrict or define host key directories and SSH configuration files during initialization, pgAdmin inadvertently defaulted to standard system-level behaviors associated with the underlying operating system account running the service process. This oversight meant that when a user initiated an SSH tunnel through the web interface, the application did not isolate the authentication context to the specific credentials provided by that user. Instead, it inherited the broader security posture of the host environment, effectively merging the identity of the end-user with that of the system-level service account responsible for running pgAdmin.
This architectural flaw creates a severe operational impact where any authenticated user can leverage the SSH agent or private keys stored in the home directory of the operating-system account executing pgAdmin. In practical terms, if an attacker gains access to the web interface as a low-privileged user, they are not restricted by their own local identity files or password configurations alone. The application logic allows for fallback mechanisms that check ~/.ssh/config and load unencrypted private keys from the service account's directory without verification against the requesting user's storage. Consequently, an attacker can configure a tunnel to any remote host that accepts authentication via the service account’s SSH key pair. This effectively grants the attacker access to internal network resources as if they were the privileged system process running pgAdmin, bypassing intended access controls and potentially exposing sensitive backend infrastructure or databases that are only accessible through specific trusted keys held by the server administrator.
From a classification perspective, this vulnerability aligns with CWE-287, which describes Improper Authentication, specifically in scenarios where default configurations lead to privilege escalation. It also relates closely to CWE-913, as it involves improper control of dynamically managed code resources leading to unintended access paths via inherited environment contexts. In the context of the MITRE ATT&CK framework, this behavior facilitates lateral movement and credential abuse by allowing an attacker to pivot through SSH tunnels using credentials they do not possess but are available in the execution environment. The lack of strict isolation between user-specific configurations and system-wide defaults violates fundamental principles of least privilege and secure default configuration, creating a pathway for unauthorized access that persists across different user sessions within the same server instance.
The remediation strategy implemented in pgAdmin 4 version 9.19 addresses this issue by enforcing strict separation of authentication contexts in server mode. The updated logic ensures that SSH tunnels are established exclusively using the identity file or password explicitly configured by the individual user initiating the connection. This change effectively disables the fallback behavior that previously allowed access to ~/.ssh/config and system-level keys, ensuring that an error is returned if a specified identity file cannot be found within the user's own storage rather than silently falling back to privileged locations. It is important to note that this fix applies specifically to server mode deployments; desktop mode remains unchanged as it operates under different security assumptions regarding local user isolation. Organizations running pgAdmin 4 in server mode must upgrade immediately to mitigate the risk of unauthorized lateral movement and data exfiltration through compromised SSH tunnels, while also auditing existing configurations to ensure no residual dependencies on system-level SSH agents persist in custom deployment scripts or overrides.