pgadmin.org pgAdmin 4, CVE-2026-116241: a new CVE scored 9.9

The bottom line

If you run pgAdmin 4 before 9.19, act now: limit who can sign in to it, and ask your IT provider to move to 9.19 once it is released. No release is confirmed yet. If you do not run pgAdmin 4, stop here.

Free analysis report · 9 pagespgadmin.org pgAdmin 4, CVE-2026-116241: a new CVE scored 9.9The same note as a document you can keep or forward: what the sources say, who is affected, and what to do first.Download the analysis report →

At a glance

Does this apply to you?

What it is

A user with an ordinary database role can make pgAdmin's Import/Export tool run an operating-system command on the pgAdmin host, as the account running pgAdmin. The record's description is cut off, so it does not state the full impact.

Why it matters

Our reading: the command runs on the pgAdmin host, not on the database server. An ordinary database role is enough, so a low-privilege account can become a foothold on the machine used to manage your databases. The record scores it 9.9 under CVSS 3.1 and names CWE-78 and CWE-115. The fix is not yet released, so exposure reduction is the only step available today.

What the vendor's advisory says

We read one page on github.com. In short:

• The tracking issue was opened on 23 October 2026 as a placeholder. It says details will be published with the pgAdmin 4 9.19 release notes.
• Two commits were added to the issue on 26 October 2026. One rejects a backslash in a double-quoted identifier in Import/Export. The other rejects a backslash or null byte in a schema, table or column name.
• The issue shows no assignee, milestone or linked pull request. It names no workaround and lists no other flaws.

Exposure by situation

These priorities are our judgement from what the sources say about who can use the flaw and how. They are not vendor ratings.

Things people will get wrong

• It is fixed, so we are safe. The tracking issue says the fix is pending for 9.19. Commits exist, but no source confirms a release.
• It needs a database administrator account. The record says an ordinary database role can trigger it.
• It only affects the database server. The record says the command runs on the pgAdmin host, as the account running pgAdmin.
• It is not on CISA's list, so ignore it. The record is new. Not being listed when read says nothing about whether anyone is using it.

How we would triage it

This is our judgement.

The commands only read: they print a version or list what is installed. They come from general knowledge of this kind of product, not from the sources, so check them against the vendor's page before you run them. Words in capitals are for you to fill in.

Step 1: Find where pgAdmin 4 runs

• Ask your IT provider to list every machine and container running pgAdmin 4, including desktop installs.
• Record the version of each. Anything earlier than 9.19 is in the affected range.

pip show pgadmin4
docker ps --format '{{.Names}} {{.Image}}'

Step 2: Reduce who can reach it

• Limit sign-in to people who need pgAdmin. Remove accounts and database roles that do not.
• Keep it off the public internet where you can. The sources name no workaround, so this is our reading.

Step 3: Update when 9.19 is released

• Watch for the pgAdmin 4 9.19 release notes, which the tracking issue says will carry the details.
• Move every affected install to 9.19 once it is out, then restart pgAdmin.

Step 4: Confirm the result

• Ask for the running version on each install, in writing.
• Confirm that nobody uses the Import/Export tool on queries from untrusted accounts in the meantime.

To close it, read the version from the product itself, not from an old inventory, and save the output with the date. If you cannot update today, write down who owns it, the new date, and what limits exposure until then.

Send this to your IT provider

Copy it, change the names and dates, and send it. It is a draft for you to check, not a template tested with any provider.

Hello. We would like to know whether we run pgAdmin 4 anywhere, including desktop installs and containers, and which version each one is. CVE-2026-116241 affects versions before 9.19, and the vendor's tracking issue says the fix is pending for 9.19. Please tell us where it runs and who can sign in to it. Please limit access until 9.19 is available, then update. Could you confirm the installed versions and the update in writing by [date]? Thank you.

The weakness behind it

The record classes this as CWE-78 and CWE-115.

• CWE-78 →What this kind of mistake is, and which exploited vulnerabilities share it.

The sources, in their words

The CVE record:

pgAdmin 4's Import/Export Data tool wraps a user's query export in a psql \copy (...) TO command and checks that the query's parentheses are balanced so that nothing can escape the wrapper. The check rejected a backslash inside a single-quoted string, but not inside a double-quoted identifier, where it treated the next double quote as closing the identifier. psql's \copy parser applies the connection's escape character to whichever quote opened a token, so with standard_conforming_strings off a backslash-escaped double quote does not close the identifier. pgAdmin's and psql's view of the quoting then diverged, a closing parenthesis hidden from the check ended the \copy (...) wrapper, and a …

Versions of pgadmin.org pgAdmin 4 the record lists as affected:

• all versions up to, but not including, 9.19

What we do not know yet

• Whether pgAdmin 4 9.19 has been released. The sources only say the fix is pending for it.
• The full impact. The record's description is cut off after saying an ordinary database role can trigger it.
• Whether any workaround exists. The sources name none.
• Whether anyone is exploiting it. The record is new and CISA did not list it when read.
• Exploitation is not recorded. That is not the same as none.
• This is a new record: scores, versions and wording can change in the first days, and they are as at 31 October 2026. We read the vendor pages listed under Sources; nothing here has been tested.
• The sections headed "The bottom line", "Does this apply to you?", "What it is", "Why it matters", "Exposure by situation", "Things people will get wrong", "How we would triage it" and "Send this to your IT provider" are our interpretation of the sources, not a statement by CISA or the vendor.

• The day's CVE highlight →The three new records we picked that day, and how we chose them.
• Today's mission →Every exploited vulnerability from the last seven days, in the order their deadlines fall.