PostgreSQL Patches 12-Year-Old Logical Decoding Flaw (CVE-2026-6471)

PostgreSQL's security team has shipped fixes for CVE-2026-6471, a CVSS 7.2 flaw in logical decoding that allows any role carrying the REPLICATION attribute to run arbitrary code as the operating-system account the database runs under. Per the official advisory, the bug has been present since logical decoding shipped in PostgreSQL 9.4 in 2014 — about twelve years in production code.

How the exploit works

Logical decoding lets a replication client stream row-level changes out of the write-ahead log through a pluggable "output plugin." According to the advisory and researcher writeups, the CREATE_REPLICATION_SLOT command passes the plugin name straight to the server's library loader without the path restrictions normally applied to superuser-only operations. A REPLICATION-privileged (but non-superuser) client can therefore point that parameter at an arbitrary file path — including a network path over SMB or NFS — and get the server to dlopen and execute it, as the OS account running PostgreSQL. Researchers Vladimir Tokarev and Yu Kunpeng, who published the technical details through Cyera Research on September 1 under the name "PostGREShell," describe the resulting access as effectively permanent code execution and a path to superuser.

Who is actually exposed

Two conditions have to be true: the server must be running with wal_level = logical, and an attacker needs a role with the REPLICATION attribute. Neither is exotic. Logical replication underpins many change-data-capture pipelines, cross-version upgrades, and analytics feeds, and the accounts backup tools, standby servers, and monitoring agents use are routinely granted REPLICATION without much scrutiny — meaning the practical attack surface is wider than "a rogue superuser," which is the threat model this class of privilege was designed to sit below.

What the fix changes

The patched releases — 18.6, 17.11, 16.15, 15.19, and 14.24 — introduce a new server parameter, output_plugin_libraries, that allow-lists which libraries may be loaded as logical decoding output plugins. It defaults to pgoutput, test_decoding, the two built-in plugins most deployments actually need, closing off arbitrary-path loading by default.

What to do now

• Patch to 18.6, 17.11, 16.15, 15.19, or 14.24 as soon as your change window allows.
• Audit every role with the REPLICATION attribute and remove it from accounts that don't strictly need it — check backup, CDC, and monitoring service accounts specifically.
• If you can't patch immediately, restrict replication connections in pg_hba.conf to known hosts, and block outbound SMB (445) and NFS (2049) from database servers to reduce the network-path loading vector.
• After patching, review output_plugin_libraries to confirm it reflects only the plugins your environment actually requires.

This is a reminder that privilege tiers below superuser are worth threat-modeling on their own terms — the REPLICATION attribute was never meant to be equivalent to superuser, and for twelve years it quietly was.