pgAdmin 4: SSH tunnels use the pgAdmin service account's own SSH identity
Affects pgAdmin 4 before 9.19 running in server mode, where users share the operating-system account pgAdmin runs as. CVSS rates it high. Fixed in 9.19.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 9.19
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
pgAdmin 4 is affected, specifically its SSH tunnel feature when running in server mode. Before the fix, any user could configure a tunnel that silently used the SSH keys, SSH config, and agent of the operating-system account running pgAdmin, letting them log in to hosts that trusted that account without having credentials of their own.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- pgadmin.org pgAdmin 4
fixed in 9.19
References 2
GitHub · pgadmin-org/pgadmin4
Questions about CVE-2026-116242
What does this mean?
In server mode, a user could configure an SSH tunnel to a host reachable by the pgAdmin service account. That tunnel could authenticate as the service account using its SSH key, without the user holding credentials of their own.Source: github.com
Am I affected, and how do I check?
Versions before 9.19 are listed as affected. The setup involved is pgAdmin 4 running in server mode, where users share the operating-system account pgAdmin runs as, and an SSH tunnel host that accepts the service account's SSH key or credentials. Check the pgAdmin version and whether server mode is in use.Source: github.com
What should I do about it?
Upgrade to pgAdmin 4 version 9.19 or later, the fixed version listed for this issue.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data