PostGREShell: High-Severity Privilege Escalation Vulnerability in PostgreSQL Logical Decoding (CVE-2026-6471)
September 12th, 2026
High
.jpg)
Our Cyber Threat Intelligence Unit is tracking a vulnerability in PostgreSQL, tracked as CVE-2026-6471 and referred to as PostGREShell. The vulnerability sits in PostgreSQL's logical decoding component and stems from a missing authorization check present since logical decoding was introduced in version 9.4 in 2014. Cyera Research privately reported the issue to the PostgreSQL Security Team in February 2026, and PostgreSQL published fixed releases 18.6, 17.11, 16.15, 15.19, and 14.24 on August 13, 2026. An account holding the Replication attribute, a role routinely granted to backup tools, standby replicas, and change data capture pipelines, can use this path to execute code, escalate to database superuser, and install a persistent backdoor. As of early September 2026, there is no confirmed in-the-wild exploitation, and the vulnerability does not appear in CISA's Known Exploited Vulnerabilities catalog, though the routine nature of the Replication attribute and the widespread use of PostgreSQL warrant prompt patching.
Technical Details
Severity: High
CVE ID: CVE-2026-6471
CVSS Score: 7.2
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Vulnerability Type: Remote Code Execution, Privilege Escalation.
Component Affected: PostgreSQL logical decoding.
Affected Versions: All versions before 18.6, 17.11, 16.15, 15.19, and 14.24 (PostgreSQL 9.4–18). Branches earlier than 14 are end-of-life and will not receive a fix; those instances must be upgraded to a supported branch.
Attack Chain:
Access requirement: Exploitation requires network access to the PostgreSQL server, an authenticated account holding the Replication attribute (CVSS Privileges Required: High), and a server configured with wal_level = logical. The Replication attribute is commonly assigned to backup, standby replication, and change data capture accounts.
Root cause: The logical decoding code path does not apply the superuser authorization check that other library-loading operations in PostgreSQL enforce, allowing a Replication-privileged session to specify which plugin the server loads.
Exploitation mechanics: An attacker creates a logical replication slot and supplies a plugin name containing a full file system path, directory-traversal sequences, or, on Windows, a UNC path. PostgreSQL passes this value directly to the operating system's library loader (dlopen on Linux/macOS, LoadLibrary on Windows), executing the attacker's code with the privileges of the PostgreSQL service account.
Post-exploitation: Cyera Research demonstrated that code running in this context can modify the pg_authid system catalog to grant permanent PostgreSQL superuser privileges, then establish persistence by rewriting pg_hba.conf to allow passwordless connections and registering the malicious library in shared_preload_libraries so it reloads after a restart.

Impact
Who's at risk: Any organization running an affected, unpatched PostgreSQL version with reachable Replication accounts, which covers most production deployments given how commonly that attribute is assigned to backup and replication tooling.
Data exposure: Full database and host compromise can expose customer records, financial data, and other sensitive information stored in the database.
Credential and key theft: Attackers can read credentials and cryptographic material accessible to the PostgreSQL server process.
Persistence and recovery cost: Backdoors installed through this path are designed to survive administrator remediation and service restarts, extending downtime and recovery cost.
Business and compliance impact: Because PostgreSQL underpins many customer-facing applications, exploitation can disrupt operations and create regulatory exposure under data protection requirements.
Detection Method
Query pg_roles for accounts where rolreplication is true and confirm each still requires the privilege.
Monitor pg_replication_slots for new logical slots created outside expected backup or CDC schedules, particularly with unfamiliar plugin names.
Flag CREATE_REPLICATION_SLOT or logical decoding commands where the plugin argument contains "/", "", "..", or a UNC-style prefix.
Alert on unexpected changes to pg_hba.conf, especially entries permitting trust or passwordless authentication.
Monitor pg_authid for unexpected changes granting rolsuper = true outside change management.
Alert on unrecognized libraries added to shared_preload_libraries or new files in the PostgreSQL plugin directory.
Check SHOW wal_level; on production instances; servers with wal_level = logical and reachable Replication accounts are the ones exposed to this path and should be prioritized for review.
Indicators of Compromise
There are no Indicators of Compromises Observed

Recommendations
Apply PostgreSQL 18.6, 17.11, 16.15, 15.19, or 14.24 (or later) immediately based on your current branch. Upgrade any instance on a pre-14 branch to a supported version, as those branches will not receive a fix.
Restrict the Replication attribute to only the accounts that require it, and revoke it from all others.
Enforce MFA and strong authentication for all administrative and service accounts with database access.
Restrict pg_hba.conf replication entries to known, trusted IP addresses; never use 0.0.0.0/0.
Monitor the log sources above and enable alerting for replication slot creation, pg_hba.conf changes, and pg_authid modifications.
Isolate database backups and verify restore procedures remain functional after patching.
Review the new output_plugin_libraries parameter after patching and add any legitimate third-party plugins (e.g., wal2json, decoderbufs) your environment depends on, since the patch restricts logical decoding to pgoutput and test_decoding by default.
Until patching is complete, reduce exposure to the Windows UNC-path exploitation vector by blocking outbound SMB (port 445) and NFS (port 2049) traffic from database servers and disabling autofs where it is not needed.
Conclusion
CVE-2026-6471 (PostGREShell) allows an account holding the routine Replication attribute to escalate to full PostgreSQL superuser and establish a persistent backdoor, placing any organization running an affected, unpatched instance at risk of database and server compromise. Our Cyber Threat Intelligence Unit recommends applying the available patches and auditing all Replication-privileged accounts as an immediate priority.