PostgreSQL Patches 12-Year-Old Flaw Enabling Code Execution

“Previously, a replication user could select any loadable library for logical decoding, allowing exploits of various sorts.” That blunt passage from the PostgreSQL 18.6 release notes frames a vulnerability—tracked as CVE-2026-6471—that has quietly lived in PostgreSQL since logical decoding arrived in 2014.

CVE-2026-6471: replication roles able to run operating‑system code

PostgreSQL released fixes on August 13 for a flaw that lets an account carrying the REPLICATION attribute execute arbitrary code as the operating‑system user running the database server. The bug has been present since logical decoding was introduced in PostgreSQL 9.4 (2014) and affects versions earlier than the patched releases: 18.6, 17.11, 16.15, 15.19, and 14.24. The vulnerability carries CVSS 7.2 and is tracked as CVE-2026-6471.

How an output plugin name becomes executable code

Cyera Research, whose write‑up by Vladimir Tokarev on September 1 named the flaw "PostGREShell," detailed the exploitation path. The plugin name supplied in a CREATE_REPLICATION_SLOT command is forwarded directly to the loader. PostgreSQL's usual LOAD‑time restriction that confines non‑superusers to an administrator‑controlled directory does not apply on the replication path. The replication protocol's parser accepts almost any character inside a double‑quoted plugin name, including path separators and ../ traversal, so a full filesystem path reaches the loader as typed.

On Windows, a server will resolve a network path over Server Message Block (SMB) and fetch the library from an attacker‑controlled machine without writing files to disk. On Linux and macOS the same remote fetch requires enabling Network File System (NFS) automounting; elsewhere an attacker must already be able to write a file to disk. Code loaded this way runs inside the backend as the postgres operating‑system user.

Cyera's test plugin demonstrated both privilege escalation—writing the role catalog to make the replication account a PostgreSQL superuser—and persistence, installing three mechanisms that survived a server restart.

The patch: output_plugin_libraries and the operational tradeoff

The upstream fix introduces a new server parameter, output_plugin_libraries, which whitelists which libraries may be loaded as logical decoding output plugins. The default list is 'pgoutput, test_decoding'. Installations that use other plugins—wal2json and decoderbufs are explicitly named in distribution advisories—will see logical decoding refused after updating until administrators add those libraries to the whitelist and reload the server configuration.

Jacob Champion, who authored the commit, wrote that "REPLICATION users were not previously subject to restrictions on output plugin paths, so they were able to bypass LOAD‑time protections during logical decoding." PostgreSQL rejected applying the existing LOAD restriction retroactively because doing so would require third‑party output plugins to be installed under $libdir/plugins.

Failed loads now log: ERROR: library "..." may not be used as an output plugin, with a hint naming the setting, so administrators can diagnose blocked plugins without restarting the server.

Immediate steps, packaged fixes, and outstanding gaps

• Administrators are advised to run SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; before updating to identify plugins ever used by slots.
• Update to a fixed release (18.6, 17.11, 16.15, 15.19, 14.24) or the equivalent distribution package, and add any non‑default plugin to output_plugin_libraries; reload via pg_ctl reload or SELECT pg_reload_conf(). A restart is not required.
• When migrating from version 17 or later, set the new cluster's output_plugin_libraries before running pg_upgrade --check, because the check fails if the list does not permit the old cluster's slot plugins.
• Fixed packages are available on Amazon RDS and from Debian, SUSE, and Ubuntu; Debian's advisory warns the upstream fix "requires additional changes to the configuration if some extensions are used" and names wal2json and decoderbufs. Ubuntu's USN‑8653‑1 (Aug 20) shipped fixes for 22.04, 24.04, and 26.04 LTS but did not mention the new parameter, advising only a restart after update.
• A notable gap remains: pg_createsubscriber creates replication slots with plugin 'pgoutput' without checking the new GUC, so a --dry-run passes but actual conversion fails. Hayato Kuroda of Fujitsu called this "very surprising for users" and a patch was under review but not committed as of September 4.

How backup/CDC operators, distribution maintainers, and security teams are affected

• Backup tools, standby servers, change data capture pipelines, and monitoring systems commonly hold the REPLICATION attribute; operators must inventory replication slots and add used plugins to output_plugin_libraries before rolling updates to avoid service interruption.
• Distribution maintainers (Debian, SUSE, Ubuntu) must balance shipping the security fix with guidance and packaging changes for plugins such as wal2json and decoderbufs; Debian explicitly warned of extra configuration work.
• Security teams should strip REPLICATION where not needed, restrict replication entries in pg_hba.conf to known addresses, block outbound SMB (port 445) and NFS (port 2049) from database servers, and disable autofs where unnecessary—measures Cyera recommended as interim mitigations until updates are applied.

CVE-2026-6471 remains absent from CISA's Known Exploited Vulnerabilities catalog as of September 4 and The Hacker News found no public proof‑of‑concept code on the same date. That does not erase the practical risk: replication credentials are widely used by benign tooling, and the fix introduces an operational step that administrators must take deliberately. For now the clearest path is straightforward—inventory, update, and whitelist the output plugins you actually use.

https://thehackernews.com/2026/09/postgresql-fixes-12-year-old-logical.html