pgAdmin 4 CVE-2026-116243

Requires pgAdmin running in server (multi-user web) mode with at least one non-restricted SHARED_STORAGE directory that ordinary users can upload files to; the attacker must have an authenticated pgAdmin account (PR:L) and be able to set their own utility binary-path preference. The decisive limiting factor is the platform: the file must be executable by name, which the vendor states occurs in Windows server mode, whereas on POSIX files created through pgAdmin are not executable and the flaw is not exploitable there. A related configuration risk noted in the fix is that an empty STORAGE_DIR exposes the whole filesystem, defeating the guard entirely. Exploitation does not require interaction from any other user.

This is a genuine arbitrary-code-execution flaw (CWE-426, untrusted search path) with a CVSS 4.0 base of 7.7, but the real-world risk is moderate rather than urgent because every key metric points to gated, non-automatable exploitation. The vector (AV:N/AC:H/AT:P/PR:L/UI:N) shows it is reachable over the network through the pgAdmin web UI, yet it requires an already-authenticated pgAdmin account (PR:L), a specific attack requirement (AT:P) and elevated complexity (AC:H) - namely server (multi-user web) mode, a configured SHARED_STORAGE directory writable by ordinary users, and a platform that executes a file by name. The vendor explicitly limits practical exploitation to Windows server mode, since on POSIX files created through pgAdmin are not executable. No EPSS score was supplied, the CVE is not in CISA KEV, and no public exploit was identified - the only references are the fix commit and the issue tracker, so there is no evidence of active or widespread exploitation. The vuln.today decision label is this_week, consistent with a serious-but-conditional RCE that should be patched promptly but is not an emergency. In short: high technical impact (full compromise as the pgAdmin OS account) offset by authentication, non-default configuration and platform prerequisites, making this a targeted-opportunity issue rather than a mass-exploitable one.

An authenticated low-privilege user of a Windows pgAdmin server-mode deployment uploads an executable file into a non-restricted SHARED_STORAGE directory, then sets their utility binary-path preference to point at that file. When pgAdmin invokes a tool such as pg_dump, pg_restore, pg_dumpall or psql, it runs the attacker's executable as the operating-system account running pgAdmin, yielding code execution on the host. No public exploit code is known; the referenced material is the vendor fix commit and issue, not a working PoC.