PostgreSQL has issued security updates to fix a vulnerability that lets accounts with replication privileges execute arbitrary code as the operating system user running the database server. The flaw, designated CVE-2026-6471 with a severity score of 7.2, has existed since the database introduced logical decoding in version 9.4 back in 2014. According to The Hacker News report published September 5, the issue affects all versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24.
To exploit the weakness, an attacker needs an account carrying the REPLICATION attribute and access to a server configured with wal_level set to logical. Backup utilities, standby database servers, change data capture pipelines, and monitoring tools regularly hold that attribute, according to the report. The fix, released August 13, introduces a server parameter named output_plugin_libraries that specifies which libraries can be loaded as logical decoding output plugins, with a default whitelist of 'pgoutput, test_decoding'. Installations running any other output plugin—including wal2json and decoderbufs—will see logical decoding blocked after updating until an administrator manually adds the library to that list and reloads the server configuration. Researchers Vladimir Tokarev and Yu Kunpeng reported the problem to the PostgreSQL Project, with Tokarev publishing a detailed technical breakdown on September 1 for data security company Cyera Research, which dubbed the vulnerability PostGREShell.
The PostgreSQL Global Development Group stated in its 18.6 release notes that "previously, a replication user could select any loadable library for logical decoding, allowing exploits of various sorts." The report explains that the plugin name provided in a CREATE_REPLICATION_SLOT command is passed straight to the library-loading function. PostgreSQL's existing safeguard on plugin paths, which limits non-superusers to a single administrator-controlled directory, is never invoked on the replication pathway, and the replication protocol's parser accepts nearly any character inside a double-quoted plugin name, including path separators and ../ traversal sequences. On Windows systems, the server can resolve a network path over Server Message Block and retrieve the library from an attacker-controlled machine without writing anything to the target, while on Linux and macOS the same outcome requires Network File System automounting to be enabled.
The weakness matters because code loaded through this path runs inside the database backend process as the postgres operating system user. Cyera's proof-of-concept plugin wrote directly to the role catalog to elevate the replication account to a PostgreSQL superuser and established three persistence mechanisms that survive a server restart. Jacob Champion, who authored the fix, explained in the commit message that adding the standard LOAD restrictions to the replication path would retroactively force all third-party output plugins to be installed under the $libdir/plugins directory, breaking existing setups. Administrators are advised to run SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; before updating, then upgrade to the patched versions and add any non-default plugins to output_plugin_libraries before reloading the configuration—no restart required. Fixed packages are available on Amazon RDS for all five supported branches, as well as from Debian, SUSE, and Ubuntu, though Ubuntu's advisory makes no mention of the new parameter and simply tells administrators to restart PostgreSQL after the update. PostgreSQL 14 stops receiving fixes on November 12, 2026.
Until the update can be applied, the report recommends stripping the REPLICATION attribute from accounts that don't need it, limiting 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 isn't needed. As of September 4, CVE-2026-6471 had not been added to CISA's Known Exploited Vulnerabilities catalog, and no public proof-of-concept code was available in public repositories. The twelve-year exposure window underscores how privilege boundaries in database systems can erode silently as new features layer onto old architectures. Organizations running custom output plugins face an immediate trade-off between security posture and operational continuity, with no automated path to reconcile the two.