pgAdmin 4 v9.19 Ships With 15 Security Fixes Targeting Server Mode
The popular PostgreSQL GUI just got 136 changes, but the real story is how aggressively it reworks multi-tenant authentication, credential handling, and OS command construction.
pgAdmin 4 v9.19 is out, and the pgAdmin Development Team isn't hiding the ball. Announced today, this release bundles 136 changes, of which 15 are security fixes running from CVE-2026-116238 through CVE-2026-116252.
That pairing isn't accidental. Thirteen feature and bug-fix commits alongside fifteen distinct vulnerabilities is a dense update, and the security half is doing far more work than a typical point release. It reads less like a patch and more like a full re-examination of how server-mode pgAdmin handles file paths, credentials, process environments, authentication flows, and OS command construction.
Two modes, one problem
For more than a decade, pgAdmin has been the go-to interface for anyone wrangling PostgreSQL through a browser. It's a Flask backend, a React frontend (which recently migrated to React 19), and an Electron runtime bundled for users who'd rather not stand up a web server.
There are really only two ways to run it. Desktop mode is a single-user, standalone app. Server mode is a multi-user web deployment with its own accounts, authentication backends, and per-user storage, the one teams and hosted environments rely on, and the one with the biggest attack surface.
That distinction matters here. Nearly every fix in v9.19 lands in server mode, because that's where a flaw can stop being "one user's bad day" and become "any user touching another user's secrets, or the service account's files."
If you're keeping score on how serious this is: pgAdmin sits directly between humans and production databases. A real flaw in the tool can mean unauthorized access to entire clusters, or even command execution on the host running the database service.
The bigger picture, if you want one, has been building for over a year. Flip through the pgAdmin security advisories page and you'll see the arc clearly: a critical RCE via eval() in v9.2, a PLAIN-format restore RCE in v9.10, a cross-user credential leak in the v9.15 security drop, and so on. v9.19 is the latest step in what's effectively an ongoing remediation campaign, and several fixes even acknowledge being "incomplete" follow-ups to earlier CVEs. That's unusual honesty for a desktop tool, and it signals this hardening is iterative rather than one-and-done.
The fixes that actually bite
The fifteen vulnerabilities cluster into a handful of recurring themes. A few are worth spelling out because they're the ones real deployments would hit.
Command injection remains the headline. CVE-2026-116241 lets a query-based export smuggle a live TO PROGRAM clause past the \copy (...) parenthesis guard by exploiting a backslash inside a double-quoted identifier, something psql only treats as an escape when standard_conforming_strings is off. The net effect is arbitrary OS command execution on the pgAdmin host. This one is explicitly an incomplete fix for the earlier CVE-2026-17566, so the fight isn't over.
Then there's the credential leakage family, which is where this batch really earns its weight. A connection path like ../<another user>/.pgpass could let one user connect with another's credentials (CVE-2026-116249). libpq could silently fall back to the service account's ~/.pgpass when no password file was configured, giving anyone access to saved secrets (CVE-2026-116247). And a server password written into the process environment and never cleaned up could be inherited by a later user's psql session (CVE-2026-116246).
Identity confusion rounds out the worst of it. An LDAP or Kerberos lookup by username alone let one account log in as a different internal user sharing that username, including the initial administrator (CVE-2026-116239). Meanwhile login limits were dodged through case differences or password-posting forms that bypassed rate-limiting entirely (CVE-2026-116238).
The remaining fixes cover path-traversal and TOCTOU races in the File Manager, service-account privilege abuse via SSH tunnels and connection services, and a clever one where a crafted database name in a materialized-view refresh was passed straight to psql's --dbname, letting libpq expand it into a full connection string and leak the user's password.
Several of these were reported by independent researchers: Theori, Blacksight, MUTED CYBERSECURITY, which is another sign the project now benefits from an external review pipeline rather than shipping on faith.
Features worth noticing
The security work will dominate headlines, but v9.19 does ship a few things people will actually use.
The Query Tool gains a new Statistics node for managing extended statistics, an option to save results as JSON or XML (with selectable encoding, an optional byte order mark, and a "copy with headers" toggle), and a duplicate-line shortcut in the editor. You can also now edit rows behind simple updatable views, not just base tables.
Server-mode users get OAuth2 server-group scoping, which lets a claim restrict which shared servers a user sees, plus the ability to skip the login page entirely when OAuth2 is your only auth source.
There's also pg_timetable support for managing chains and tasks, a nod to the now-deprecated pgAgent that Cybertec's scheduling agent has filled. It's been tested against pg_timetable 6.3.0 and later.
What admins should do first
Here's the part you shouldn't skip. v9.19 changes some server-mode behavior in ways that require planned action before you upgrade.
The biggest landmine is the password exec allowlist. Free-text Password Exec Commands are gone in server mode, and ENABLE_SERVER_PASS_EXEC_CMD is deprecated. You now define permitted commands by name in SERVER_PASSEXEC_COMMANDS, and they run without a shell and with a reduced environment.
The tricky bit is the timing. Configure that setting before your first start after upgrading. On that first start, any existing command matching a configured entry gets converted to its name, and every other command is cleared. That cannot be undone. If you leave the setting empty, conversion just gets postponed and a warning shows up at each start.
Also worth knowing: the cross-user server-sharing fix (CVE-2026-116248) isn't retroactive. Any servers a non-admin shared with everyone will persist until an admin un-shares them. Audit those before you upgrade, or you'll be chasing stale broadcasts afterward.
Connections tied to the service account's connection-service file will stop working until you list the service in SERVER_MODE_ALLOWED_SERVICES, which is empty by default. Keep in mind that listing a service shares its credentials with every user, so only add services meant for everyone.
Bottom line
It's a substantial release, and for anyone running server mode it's effectively mandatory. The combination of command injection, cross-account confusion, and credential leakage to both the service account and other users isn't something you want to defer.
For single-user desktop setups, the upgrade is lower stakes, but the extended-statistics node, updatable-view editing, JSON/XML export, and pg_timetable support still make it worth the install.
If you run server mode, the move is clear: upgrade to v9.19 or later, set up SERVER_PASSEXEC_COMMANDS before the first start so nothing gets irreversibly cleared, curate SERVER_MODE_ALLOWED_SERVICES and any non-admin shared servers, and verify SSH-tunnel and Kerberos setups that leaned on the service account's keys.
Head here to download the release.
