pgAdmin 4 v9.19 fixes 15 vulnerabilities, most of them in server mode
Serguey Asael Shinder2 min readThe pgAdmin Development Team released pgAdmin 4 version 9.19 on 31 October with 136 bug fixes and new features, including fixes for 15 security vulnerabilities numbered CVE-2026-116238 through CVE-2026-116252.
Most of the security fixes concern server mode, where one pgAdmin instance serves many users. They stop libpq falling back to the pgAdmin service account's own password file, client certificate and Kerberos credentials, stop SSH tunnels using the service account's SSH identity, fix connection file paths that could escape a user's storage directory and let one user connect with another's credentials, and stop server passwords lingering in pgAdmin's own process environment. LDAP and Kerberos logins could put a user into a different account sharing the same username, including the initial administrator (CVE-2026-116239), and the failed-login limit and password checks could be bypassed through Flask-Security's own views (CVE-2026-116238). The Import/Export tool had an OS command injection that completed an earlier, partial fix for CVE-2026-17566 (CVE-2026-116241).
Two of the changes need action at upgrade. Free-text Password Exec Commands in server mode are replaced by an administrator-defined allowlist, SERVER_PASSEXEC_COMMANDS, whose commands run without a shell; it should be configured before the first start after upgrading. Connection services in server mode are likewise restricted to an allowlist, SERVER_MODE_ALLOWED_SERVICES. Among the features are a Statistics node for managing extended statistics, editing through simple auto-updatable views and saving query results as JSON or XML.
What it means
The common thread in the server-mode fixes is identity leaking from the process to the user: credentials that belong to the account pgAdmin runs as were reachable by whoever was logged in. A desktop install is barely affected by that; a shared deployment is the target. For shared deployments the upgrade is worth scheduling now, with the two allowlists written first, because a missing SERVER_PASSEXEC_COMMANDS is the kind of change that surfaces as a broken login on Monday morning.