pgAdmin 4 9.19 fixes 15 CVEs; the worst let an ordinary user's query export run commands on the pgAdmin host

Thirteen of fifteen score 7.0 or more, and fourteen need a login

pgAdmin 4 version 9.19, released on 29 October 2026, fixes 15 security vulnerabilities, CVE-2026-116238 to CVE-2026-116252. Read one by one, the 15 CVE records give 13 of 15 a CVSS 4.0 base score of 7.0 or more, and two of them, 9.4 and 9.2, are rated critical (derived: counted from the records). The same records give 14 of 15 an attack vector that needs a low privilege login (PR:L). The one that needs none, CVE-2026-116238, is a way round pgAdmin's limit on failed logins.

The worst, CVE-2026-116241 at 9.4, turns an ordinary user's query export in the Import/Export Data tool into an operating system command on the pgAdmin host, run "as the operating-system account running pgAdmin", in the record's words. It is the second time in 91 days that the same bracket check has been beaten (derived: the earlier flaw, CVE-2026-17566, is listed as fixed in the 9.17 release notes dated 30 July 2026).

What those counts do not establish: a 9.4 is not evidence that anyone has used the flaw, and it is not a flaw reachable by a stranger on the internet. None of the 15 records carries a CISA exploitation assessment, CISA's Known Exploited Vulnerabilities catalogue lists no pgAdmin entry, and the vector itself says a login is needed. Twelve of the 15 records describe the flaw in server mode, where many people share one pgAdmin; the other three do not state a mode. Everything here was read from the primary pages between 14:27 and 14:38 GMT on Sunday 1 November 2026: pgAdmin's news page and release notes, the 15 CVE records, the GitHub advisory and the fixing commit.

What pgAdmin released, and when the records followed

pgAdmin's news page dates the release 29 October 2026 and says it "includes 136 bug fixes and new features, including fixes for 15 security vulnerabilities". The 9.19 release notes give the same date and describe each fix at length, with a warning at the top about a change that cannot be undone on first start (covered below).

The fix came before the write up. The fixing commit for the worst flaw was committed on 24 October, five days before the release (derived). The 15 CVE records, assigned by the PostgreSQL CNA, were all published on 30 October between 19:55:11 and 19:55:20 UTC, one day after the release (derived). Every record gives the same affected range: pgAdmin 4 "before 9.19". No record names a narrower range, so every earlier version is in scope for each of the 15.

The tracking issue named in the record, issue 10663, was still open when read, titled "Internal tracking: pending fix for 9.19", with a placeholder body. The release notes credit the worst flaw to a researcher at Xint by Theori; other fixes are credited to a researcher at Blacksight LLC and to MUTED CYBERSECURITY S.L. Several of the 15 list no outside finder, only pgAdmin's own developers and reviewers.

How a query export reached the operating system

The Import/Export Data tool can export the result of a query rather than a whole table. pgAdmin does this by wrapping the user's query inside a psql \copy (...) TO command and handing the line to psql. psql's \copy can also write to a program instead of a file, so the wrapper is the safety boundary: if anything in the query closes the brackets early, the text after them becomes part of psql's own command.

To stop that, pgAdmin counts the brackets in the query before it builds the line. According to the record for CVE-2026-116241, that count handled a backslash inside a single quoted string but not inside a double quoted identifier (a quoted name of a table or column). pgAdmin treated the next double quote as the end of the identifier. psql does not always agree: its \copy parser applies the connection's escape character to whichever quote opened a token, so with the setting standard_conforming_strings off, a backslash before a double quote escapes it and the identifier carries on.

The two programs then disagree about where the identifier ends. A closing bracket that pgAdmin counted as inside the name is, for psql, outside it, and it ends the wrapper. What follows is a live TO PROGRAM clause. The commit message adds the timing that matters: psql starts the program itself, "before the backend sees the statement at all", so the command runs on the pgAdmin host even though the database then rejects the statement as a syntax error.

Zoom

Two facts in the record turn this from a curiosity into a real exposure. First, "An ordinary database role can turn standard_conforming_strings off for itself": the setting the trick needs is not reserved to administrators. Second, "the Import/Export Data permission is granted to non-administrators by default". The commit message names that permission as tools_import_export_data. So the precondition is an ordinary pgAdmin account and an ordinary database login, nothing more.

The fix in 9.19 does not try to guess which reading psql will use. It "rejects any backslash inside a double-quoted identifier, as was already done for single-quoted strings, since its meaning depends on a server setting that cannot be known reliably when the query is validated". The release notes add that a backslash or null byte in the schema, table or column names of an export or import is now refused too, because those reached the same \copy command another way.

The same guard, beaten twice in 91 days

The record calls CVE-2026-116241 "a bypass of the fix for CVE-2026-17566". The CVE-2026-17566 record describes the first break of the same check: it assumed a backslash before a single quote was always an escape, which is wrong under PostgreSQL's default, so a single quote closed a string where pgAdmin thought it had not. That fix rejected any backslash inside a single quoted string. The new flaw is the mirror image, in double quotes, and runs the other way: this time the setting has to be turned off.

One detail does not line up, and it matters to anyone who stopped at 9.17. The 9.17 release notes, dated 30 July 2026, list the CVE-2026-17566 fix. The CVE record for it gives the affected range as "lessThan" 9.18, which by its own terms includes 9.17. The two primaries disagree; this briefing reports both and does not choose. It makes no difference to the advice: 9.19 is the only version outside the range of both flaws. (The 9.18 release notes, dated 17 September 2026, fixed four other CVEs, CVE-2026-86861 to CVE-2026-86864.)

This is the friendly name problem in its plainest form. The release notes call the check the "\copy (...) parenthesis-balance guard", and a guard sounds like a control. It was a second, hand written model of psql's parser, and it had to agree with the real parser in every quoting mode to be safe. It failed in July with single quotes and in October with double quotes. The safer reading of the 9.19 fix is the one pgAdmin itself gives: when a character's meaning cannot be known, refuse it.

What a 9.4 encodes, and what it does not

The CVSS 4.0 vector for CVE-2026-116241 is network reachable (AV:N), low complexity (AC:L), low privileges required (PR:L), no user interaction, and high impact on confidentiality, integrity and availability both of pgAdmin and of systems beyond it (SC, SI and SA all high). The subsequent system scores reflect that a command on the pgAdmin host is a foothold next to every database pgAdmin connects to. The CVSS 3.1 score in the same record is 9.9.

What the score does not establish. PR:L means an attacker needs a login: here, a pgAdmin account with the default permission and a database role it can connect with. The score does not say whether anyone has used the flaw. It does not say how many pgAdmin instances run in server mode, how many are reachable from the internet, or how many grant accounts to people outside the database team. The GitHub advisory mirrors the record, is marked unreviewed, and lists no affected package; it also shows an EPSS score of 0.324 per cent (25th percentile), a model's estimate of the chance of exploitation in the next 30 days of exploitation activity, not an observation.

Exploitation status, time stamped: none of the 15 records carried a CISA ADP container when read at about 14:27 GMT on 1 November, or when the worst one was read again at 14:38 GMT, so CISA had not published its SSVC assessment for them. The CISA Known Exploited Vulnerabilities feed, catalogue version 2026.10.30 released at 17:02 UTC on 30 October (about three hours before the records were published), contains no pgAdmin entry. For the earlier CVE-2026-17566, CISA's assessment dated 31 July 2026 recorded Exploitation "none" and Automatable "no". None of this proves the new flaws are unused; it means no primary source read for this briefing says they have been used.

All fifteen, grouped by what a user could reach

Grouped by what each flaw let a user reach (the grouping is this site's, the scores are the records'), the release has a clear shape. Two flaws reach commands on the pgAdmin host. Six reach another user's account, session or saved password. Four make pgAdmin use its own service account's credentials on a user's behalf: SSH keys, Kerberos tickets, connection service entries, the password file and client certificate. Three let a user act on files outside their storage directory.

Zoom

The service account cluster deserves a second look because it changes the question an administrator asks. In server mode, pgAdmin runs as one operating system account for everyone. Before 9.19, if a server entry had no password file, client certificate or SSH key of its own, libpq or the tunnel library quietly fell back to whatever that account held. So the exposure is not only what pgAdmin users can do; it is what the pgAdmin account can already reach, lent to every user.

Who is exposed: server mode, shared hosts and containers

pgAdmin's server deployment page is direct about the default: "From pgAdmin 4 v2 onwards, server mode is the default configuration. If running under the desktop runtime, this is overridden automatically." In server mode users log in, and file storage is restricted to a directory per user, so "Users do not have access to the complete filesystem of the server." That separation is what most of the 15 flaws broke. A reasonable reading (inference, not a statement in the docs) is that any pgAdmin not started through the desktop application, whether a Python wheel under a web server or the container image, is in server mode unless someone changed it.

For the container, pgAdmin's container deployment page says: "pgAdmin runs as the pgadmin user (UID: 5050) in the root group (GID: 0) in the container." That is the account the worst flaw runs commands as, inside the container. The same page documents a PGPASS_FILE variable whose file is "copied into the container and used as the .pgpass file". CVE-2026-116247 describes libpq falling back to the service account's ~/.pgpass; whether a given container's copied file is exposed that way depends on how its servers were configured, which this briefing cannot check (inference).

For a service install, the same server deployment page tells administrators to make pgAdmin's directories writable "by the user that the web server processes will be running as, e.g. apache or www-data". On such a host, the worst flaw's commands would run as that account, with whatever it can reach: the configuration database, the storage directories and any credentials in its home directory.

Desktop mode is different. Five records say outright that desktop mode is not affected or is unchanged; seven more describe the problem only in server mode. Three records, including the worst, do not state a mode. In desktop mode one person runs pgAdmin as themselves, so a command run as the pgAdmin account is a command run as that person: the record does not say the flaw is harmless there, and this briefing does not assume it.

What the record states, and what it does not

Read this before upgrading: what 9.19 changes on first start

Several fixes close a hole by removing behaviour some deployments rely on. The release notes are specific, and an administrator who upgrades blind may find servers that stop connecting:

• Password Exec Commands. In server mode free text commands are no longer run. The notes say to set SERVER_PASSEXEC_COMMANDS before the first start after upgrading, because on that start every existing command that does not exactly match a configured entry "is cleared, which cannot be undone".
• Connection services. A service can be used only if listed in SERVER_MODE_ALLOWED_SERVICES, which is empty by default; the notes advise listing it "ideally before upgrading" and warn that listing a service shares its credentials with every pgAdmin user.
• SSH tunnels. In server mode tunnels no longer use the service account's keys, ~/.ssh/config or agent; each needs an identity file in the user's storage or a password.
• Password files and client certificates. Deployments relying on the service account's files must configure them on each server.
• File paths. Servers whose file paths reach outside the storage directory stop connecting until the files are moved into it or into a shared storage directory.
• Shared servers. The sharing fix "is not retroactive": servers shared by non administrators before the upgrade stay shared, and pgAdmin only logs a warning about each at startup.
• Kerberos. The notes say to upgrade the libpq used by pgAdmin and its utilities to version 16 or later, because the protection relies on a libpq 16 option.

What to do, in order

Technical details

What the primaries print, copied exactly. No query text, payload or test case from the fixing commit is reproduced; the commit message and the earlier record both carry an example query, and it is deliberately left out.

Affected range. The affected entry from the CVE-2026-116241 record. The other 14 records carry the same range. A defender compares the running version against lessThan.

{
  "vendor": "pgadmin.org",
  "product": "pgAdmin 4",
  "versions": [
    {
      "status": "affected",
      "version": "0",
      "lessThan": "9.19",
      "versionType": "custom"
    }
  ],
  "defaultStatus": "unaffected"
}

Scores. The CVSS 4.0 and 3.1 vector strings for the three highest scoring records, as printed in each record's metrics. Note the one PR:N among them, CVE-2026-116238.

CVE-2026-116241  cvssV4_0  9.4  CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
CVE-2026-116238  cvssV4_0  9.2  CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
CVE-2026-116239  cvssV4_0  8.9  CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:N
CVE-2026-116241  cvssV3_1  9.9  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVE-2026-116238  cvssV3_1  8.1  CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2026-116239  cvssV3_1  8.5  CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

All fifteen. Each record's CVSS 4.0 base score, severity and CWE identifiers, extracted from the saved records and sorted by score.

CVE-2026-116241   9.4  CRITICAL  CWE-78,CWE-115
CVE-2026-116238   9.2  CRITICAL  CWE-307,CWE-863
CVE-2026-116239   8.9  HIGH      CWE-287,CWE-639
CVE-2026-116243   7.7  HIGH      CWE-426,CWE-427
CVE-2026-116250   7.3  HIGH      CWE-367,CWE-59
CVE-2026-116249   7.2  HIGH      CWE-22,CWE-73
CVE-2026-116240   7.1  HIGH      CWE-22,CWE-367
CVE-2026-116242   7.1  HIGH      CWE-522,CWE-1188
CVE-2026-116244   7.1  HIGH      CWE-522,CWE-1188
CVE-2026-116245   7.1  HIGH      CWE-522,CWE-862
CVE-2026-116247   7.1  HIGH      CWE-522,CWE-1188
CVE-2026-116252   7.1  HIGH      CWE-88,CWE-522,CWE-918
CVE-2026-116246     7  HIGH      CWE-214,CWE-526
CVE-2026-116248     6  MEDIUM    CWE-862
CVE-2026-116251   2.3  LOW       CWE-613

Names to search for. The PostgreSQL setting the worst flaw depends on, the permission name from the fixing commit, and the configuration settings and environment variables the 9.19 release notes name. A defender greps config_local.py, container environments and the service account's environment for these before and after the upgrade.

standard_conforming_strings
tools_import_export_data
SERVER_PASSEXEC_COMMANDS
ENABLE_SERVER_PASS_EXEC_CMD
SERVER_MODE_ALLOWED_SERVICES
SHARED_STORAGE
STORAGE_DIR
MAX_LOGIN_ATTEMPTS
AUTHENTICATION_SOURCES
KRB5CCNAME
KRB5_CLIENT_KTNAME
PGPASSWORD
PGSERVICE
PGPASSFILE
PGSSLCERT
PGSSLKEY

The upgrade warning. The first sentences of the warning at the top of the 9.19 release notes, copied exactly (including the space before each comma).

In server mode, free-text Password Exec Commands are no longer run, and ENABLE_SERVER_PASS_EXEC_CMD is deprecated and ignored. Administrators now define the permitted commands by name in SERVER_PASSEXEC_COMMANDS , and users choose one of those names in the server properties. Configure SERVER_PASSEXEC_COMMANDS before the first start after upgrading: on that start, each existing command that exactly matches a configured entry is converted to its name, and every other command is cleared, which cannot be undone.

The earlier assessment. CISA's SSVC assessment in the CVE-2026-17566 record, the only one of the 16 records read that carries one.

timestamp: 2026-07-31T00:00:00+00:00
Exploitation: none
Automatable: no
Technical Impact: total
role: CISA Coordinator

The question to ask

Fifteen fixes in one release, four of them for pgAdmin lending its own service account's keys, tickets and password file to whoever was logged in, says something about how shared pgAdmin servers are built: one process, one operating system account, many users, and a bracket check standing between them and a shell. The patch closes these holes. It does not change that shape.

So the question for anyone running pgAdmin for a team is not only "have we upgraded?" It is this: if every person with a pgAdmin login could act as the account pgAdmin runs as, what could they reach, and did we mean to give them that?

Key facts