PostgreSQL Fixes 12-Year-Old Logical Decoding Flaw Enabling Replication-Role Code Execution

PostgreSQL has released updates to address a security flaw that allows an account with the REPLICATION attribute to run arbitrary code as the operating-system user running the database server.

The flaw, tracked as CVE-2026-6471 (CVSS score: 7.2), has been present since logical decoding was introduced in PostgreSQL 9.4 in 2014. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Exploitation requires an account carrying the REPLICATION attribute and a server running with wal_level = logical. Backup tools, standby servers, change data capture (CDC) pipelines, and monitoring systems routinely hold that attribute.

The fix, shipped on August 13, adds a server parameter called output_plugin_libraries that lists which libraries may be loaded as logical decoding output plugins, defaulting to ‘pgoutput, test_decoding’.

Installations using any other output plugin, wal2json, and decoderbufs

among them, will have logical decoding refused after updating until an administrator adds the library to that list and reloads the server configuration.

“Previously, a replication user could select any loadable library for logical decoding, allowing exploits of various sorts. To allow locking this down without breaking setups that worked before, introduce a whitelist of allowed output plugins,” the PostgreSQL Global Development Group said in the 18.6 release notes.

The PostgreSQL Project credited Vladimir Tokarev and Yu Kunpeng with reporting the problem.

Tokarev detailed it in a September 1 write-up for data security firm Cyera Research, which names the flaw PostGREShell.

The plugin name supplied in a CREATE_REPLICATION_SLOT command is passed directly to the function that loads the library, Cyera said.

On Windows, the server resolves a network path over Server Message Block (SMB) and fetches the library from a machine the attacker controls, writing nothing to the target, Cyera said.

On Linux and macOS, the same result requires enabling Network File System (NFS) automounting. Everywhere else the attacker needs an existing way to write a file to the server’s disk. Code loaded this way runs inside the database backend process as the postgres operating-system user.

Cyera’s test plugin then wrote the role catalog directly to make the replication account a PostgreSQL superuser. It also set up three persistence mechanisms that survive a server restart.

Cyera describes the REPLICATION attribute as a low-privilege backup credential, but PostgreSQL scored the flaw with Privileges Required set to High, a rating reproduced in SUSE’s own assessment.

PostgreSQL rejected applying its existing LOAD restriction to the replication path.

“REPLICATION users were not previously subject to restrictions on output plugin paths, so they were able to bypass LOAD-time protections during logical decoding. Unfortunately, adding the standard LOAD restrictions now would retroactively require all third-party output plugins to be installed under the $libdir/plugins directory,” Jacob Champion, who wrote the fix, said in the commit message.

Failed loads appear in the server log as ERROR: library “…” may not be used as an output plugin, with a hint naming the setting, according to the parameter’s documentation.

Administrators are advised to take the following steps –

1. Run SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; before updating to identify the output plugins in use, which will only show plugins successfully used at some point.
2. Update to 18.6, 17.11, 16.15, 15.19, or 14.24, or to the equivalent distribution package.
3. Add any non-default plugin to output_plugin_libraries and reload the configuration with pg_ctl reload or SELECT pg_reload_conf(). A restart is not required.
4. Set the new cluster’s output_plugin_libraries before running pg_upgrade –check when migrating from version 17 or later, as the check fails if the list does not permit the old cluster’s slot plugins.

Fixed packages are available on Amazon RDS for all five branches, as well as from Debian, SUSE, and Ubuntu.

PostgreSQL’s advisory covers supported branches 14 through 18 and does not address earlier ones. PostgreSQL 14 stops receiving fixes on November 12, 2026, the project said in its release announcement.

The upstream fix “requires additional changes to the configuration if some extensions are used,” Debian’s advisory warns, naming its wal2json and decoderbufs packages.

Ubuntu’s USN-8653-1, which shipped the fix for 22.04, 24.04, and 26.04 LTS on August 20, makes no mention of the parameter and tells administrators only to restart PostgreSQL after the update.

As of September 4, the wal2json project had updated its documentation to tell users to add the plugin to output_plugin_libraries, citing the CVE.

A gap in the fix is still open. pg_createsubscriber creates replication slots using pgoutput without checking the new parameter, so a –dry-run succeeds and the conversion then fails.

“pg_createsubscriber command creates replication slots with plugin ‘pgoutput’, without checking the GUC. This meant if the plugin name is not specified in the parameter, –dry-run mode passes but actual convertion fails. It’s very surprising for users and should be avoided,” Hayato Kuroda of Fujitsu said in a message to the pgsql-hackers mailing list.

A patch was under review and had not been committed as of September 4. CVE-2026-6471 remained absent from CISA’s Known Exploited Vulnerabilities (KEV) catalog as of September 4.

The Hacker News found no proof-of-concept code for it in public repositories on the same date.

Until the update can be applied, Cyera said exposure can be reduced by stripping the REPLICATION attribute from accounts that do not need it, restricting replication entries in pg_hba.conf to known addresses, blocking outbound SMB (port 445) and NFS (port 2049) traffic from database servers, and disabling autofs where it is not needed.