PostgreSQL fixes logical decoding code-execution flaw
PostgreSQL has released fixes for CVE-2026-6471, a logical-decoding vulnerability that can allow an account with the REPLICATION attribute to execute arbitrary code as the operating-system user running the database server. The issue, also called PostGREShell by Cyera Research, has existed since logical decoding arrived in PostgreSQL 9.4 in 2014 and carries a CVSS score of 7.2.
Updates are available in PostgreSQL 18.6, 17.11, 16.15, 15.19 and 14.24. Systems running earlier releases in those branches are affected when wal_level = logical is enabled. PostgreSQL’s advisory covers supported branches 14 through 18; PostgreSQL 14 is scheduled to stop receiving fixes on November 12, 2026.
Replication privilege could load attacker-selected code
The flaw lies in the logical-decoding output plugin supplied in a CREATE_REPLICATION_SLOT command. Cyera said the plugin name was passed directly to the library-loading function. Although PostgreSQL restricts plugin paths for non-superusers through its normal loading path, that restriction was not invoked for replication connections.
The replication protocol parser accepted nearly any character within a quoted plugin name, including path separators and ../ traversal. This could allow a filesystem path to reach the library loader. Code loaded through this route executes inside the database backend process as the postgres operating-system user.
On Windows, Cyera said a network path could cause the server to retrieve a library over SMB from an attacker-controlled machine without writing a file to the target. Linux and macOS deployments would require NFS automounting for a comparable route; otherwise, an attacker would need an existing ability to place a file on the server disk.
New allowlist requires deployment checks
The August 13 fix introduces output_plugin_libraries, a server parameter that defines which libraries may be loaded as logical-decoding output plugins. Its default value is pgoutput, test_decoding. PostgreSQL chose an allowlist rather than applying its standard LOAD restrictions, because that change would have required third-party plugins to be installed beneath the $libdir/plugins directory.
The operational consequence is important: installations using another plugin, including wal2json or decoderbufs, will have logical decoding refused after the update until an administrator adds that library to the parameter and reloads the configuration. A restart is not required. Debian warned that its wal2json and decoderbufs packages need this additional configuration, while wal2json documentation was updated to cite the CVE.
Actions for database teams
Administrators can identify plugins associated with existing replication slots before patching by running SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;. They should then update to a fixed version or equivalent distribution package, add required non-default plugins to output_plugin_libraries, and reload with pg_ctl reload or SELECT pg_reload_conf().
For migrations from version 17 or later, the new cluster’s allowlist must be configured before running pg_upgrade --check if old slots use non-default plugins. A separate issue affecting pg_createsubscriber was still under review as of September 4: its dry-run can succeed even when the subsequent conversion will fail because pgoutput is not permitted.
Until patching is complete, organizations can reduce exposure by removing REPLICATION from accounts that do not need it, limiting replication entries in pg_hba.conf to known addresses, blocking outbound SMB port 445 and NFS port 2049 from database servers, and disabling autofs where it is unnecessary. The immediate business implication is that patching must be paired with an inventory of replication tooling, so security remediation does not interrupt backups, standby systems, CDC pipelines or monitoring services.