**PostgreSQL** has released critical updates to mitigate a long-standing security vulnerability. Tracked as **CVE-2026-6471** with a CVSS score of 7.2, the flaw allows an account with the REPLICATION attribute to execute arbitrary code as the operating-system user running the database server. ### The Decade-Long Vulnerability This vulnerability has been present since logical decoding was introduced in **PostgreSQL** 9.4 in 2014. Affected versions include those before **PostgreSQL** 18.6, 17.11, 16.15, 15.19, and 14.24. Exploitation requires two key conditions: an account possessing the REPLICATION attribute and a server configured with `wal_level = logical`. Critically, backup tools, standby servers, change data capture (CDC) pipelines, and monitoring systems frequently hold this REPLICATION attribute, making many deployments susceptible. ### The Fix and Its Implications Shipped on August 13, the fix introduces a new server parameter named `output_plugin_libraries`. This parameter whitelists which libraries can be loaded as logical decoding output plugins, defaulting to `'pgoutput, test_decoding'`. Installations utilizing other output plugins, such as **wal2json** and **decoderbufs**, will find logical decoding refused post-update until an administrator explicitly adds their respective libraries to this new whitelist and reloads the server configuration. In their 18.6 release notes, the **PostgreSQL Global Development Group** stated, "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." ### **PostGREShell**: A Deeper Dive **Cyera Research** named this flaw **PostGREShell** in a September 1 write-up by **Vladimir Tokarev**, who, along with **Yu Kunpeng**, is credited with reporting the issue. **Cyera** detailed that the plugin name supplied in a `CREATE_REPLICATION_SLOT` command is directly passed to the library loading function. Crucially, **PostgreSQL**'s existing restriction on plugin paths, which typically confines non-superusers to an administrator-controlled directory, is not invoked on the replication path. The replication protocol's parser accepts nearly any character within a double-quoted plugin name, including path separators and `../` traversal, allowing a full filesystem path to reach the loader as typed.  On **Windows**, an attacker could resolve a network path over Server Message Block (**SMB**) and fetch the library from a controlled machine, leaving no trace on the target disk. For **Linux** and **macOS**, enabling Network File System (**NFS**) automounting could achieve a similar result. In other scenarios, an attacker would need an existing method to write a file to the server's disk. Code loaded via this method executes within the database backend process as the `postgres` operating-system user. **Cyera**'s proof-of-concept plugin demonstrated writing directly to the role catalog to elevate the replication account to a **PostgreSQL** superuser. It also established three persistence mechanisms designed to survive server restarts. Despite **Cyera** describing the REPLICATION attribute as a low-privilege backup credential, **PostgreSQL** itself, and subsequently **SUSE**, assigned a "High" rating for "Privileges Required" in their assessment. ### Why the Existing Restrictions Failed  **PostgreSQL** developers opted against applying its existing `LOAD` restriction to the replication path. **Jacob Champion**, who developed the fix, explained in the commit message 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. Unfortunately, adding the standard LOAD restrictions now would retroactively require all third-party output plugins to be installed under the `$libdir/plugins` directory." Failed loads will appear in the server log with an `ERROR: library "..." may not be used as an output plugin`, along with a hint naming the setting. ### Recommended Mitigation Steps Administrators are advised to take the following actions: 1. Before updating, run `SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;` to identify currently used output plugins. This will only show plugins successfully used at some point. 2. Update to **PostgreSQL** 18.6, 17.11, 16.15, 15.19, or 14.24, or the equivalent distribution package. 3. Add any non-default plugin to the `output_plugin_libraries` parameter and reload the configuration using `pg_ctl reload` or `SELECT pg_reload_conf()`. A full server restart is not required. 4. When migrating from version 17 or later, set the new cluster's `output_plugin_libraries` *before* running `pg_upgrade --check`, as the check will fail if the list doesn't permit the old cluster's slot plugins. Fixed packages are available on **Amazon RDS** for all five affected branches, as well as from **Debian**, **SUSE**, and **Ubuntu**. ### Remaining Gaps and Interim Protections **PostgreSQL**'s advisory covers supported branches 14 through 18, with **PostgreSQL** 14 ceasing to receive fixes on November 12, 2026. **Debian**'s advisory warns of required configuration changes for certain extensions like **wal2json** and **decoderbufs**. **Ubuntu**'s USN-8653-1, released August 20, shipped the fix for 22.04, 24.04, and 26.04 LTS, advising only a restart. A minor gap in the fix has been identified: `pg_createsubscriber` creates replication slots using `pgoutput` without checking the new parameter. This can lead to a `--dry-run` succeeding while the actual conversion fails, an issue under review by the **PostgreSQL** community. As of September 4, **CVE-2026-6471** was not yet listed in **CISA**'s **Known Exploited Vulnerabilities (KEV) catalog**, nor was public proof-of-concept code readily available. Until updates can be applied, **Cyera** suggests reducing exposure by: * Stripping the REPLICATION attribute from accounts that do not strictly require it. * Restricting replication entries in `pg_hba.conf` to known, trusted addresses. * Blocking outbound **SMB** (port 445) and **NFS** (port 2049) traffic from database servers. * Disabling `autofs` where it is not essential.