A PostgreSQL flaw that went unnoticed for roughly twelve years lets attackers turn a plain replication account into full server access. Discovered by Cyera researcher Vladimir Tokarev and dubbed “PostGREShell”, CVE-2026-6471 escalates low-privileged replication access into code execution, permanent superuser rights and a persistent backdoor.
An unchecked plugin name lands straight in dlopen
The root cause sits in PostgreSQL’s logical decoding. When a client creates a replication slot, it freely chooses the name of the output plugin. According to the advisory, that name is passed to dlopen() – or to LoadLibrary() on Windows – without any validation. Using path traversal or UNC paths, an attacker can load arbitrary compiled code into the PostgreSQL process, which then runs with the privileges of the postgres system account.
The prerequisite matters: an attacker needs an account carrying the REPLICATION attribute, not superuser rights, and the server must run with wal_level = logical. On Windows the attack is fully remote over SMB, on Linux it can trigger via automatic NFS mounts.
Superuser via catalog manipulation and persistence
The injected code can directly manipulate the internal pg_authid table to grant itself superuser status. For persistence, Cyera describes rewriting pg_hba.conf, registering in shared_preload_libraries and repeatedly re-applying privileges. A hunt on VirusTotal already surfaced 114 malicious PostgreSQL plugins.
Affected versions and mitigations
Every release from 9.4 through 18 is affected; the flaw, rated CVSS 7.2, is fixed in 18.6, 17.11, 16.15, 15.19 and 14.24. Administrators should patch promptly, strip the REPLICATION attribute from accounts that do not need it, restrict replication entries in pg_hba.conf to known addresses, and block outbound SMB (port 445) and NFS (port 2049) traffic from database servers.
Sources: Cyera Research · SecurityWeek · PostgreSQL Security
