PostgreSQL shipped the fix on 13 August 2026. Cyera published the technical detail on 1 September, naming it PostGREShell. The gap between those two dates is what responsible disclosure is supposed to look like, and it is worth saying so before the criticism starts.
The flaw is CVE-2026-6471, and the project's own summary is admirably blunt:
Missing authorization in PostgreSQL logical decoding allows a non-superuser holding REPLICATION privilege to dlopen any file visible to the operating system account running the server, via the choice of logical decoding plugin. This in turn runs arbitrary code as that account.
Versions before 18.6, 17.11, 16.15, 15.19 and 14.24 are affected. It has been present since logical decoding arrived in PostgreSQL 9.4, in 2014 — around 12 years.
What actually goes wrong
PostgreSQL already restricts where libraries can be loaded from. The ordinary LOAD command enforces a path restriction, and that restriction works.
The replication protocol parser is a second door into the same machinery, and it accepts what the first door rejects: path separators and directory traversal sequences. Point a logical decoding plugin at a path outside the plugin directory and PostgreSQL will dlopen it.
The result is arbitrary code running as the operating system account that runs the server — normally the postgres user. Cyera's proof of concept went from there to modifying the role catalogue to grant itself superuser, and established three persistence mechanisms that survive a server restart.
So the protection existed. It was just attached to one of two paths that reach the same function, and nobody checked the other one for twelve years.
Two preconditions, and you should state both
This is where reporting will go wrong, so let us be exact.
Exploitation requires:
- an account carrying the REPLICATION attribute, and
- the server running with wal_level = logical
This is a post-authentication privilege escalation. It is not a pre-auth remote code execution, and any headline that says "PostgreSQL server takeover" without the second half of the sentence is describing the impact while hiding the precondition.
PostgreSQL's own CVSS reflects that honestly: 7.2, with the vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. Note PR:H — privileges required, High.
But PR:H is doing a lot of work
Here is why the score understates the practical exposure, and this is the actual story.
REPLICATION is not superuser, and that is exactly why it gets handed out. It reads as a narrow, plumbing-level grant. In a normal estate it is held by:
- logical replica connections
- backup tooling
- change-data-capture pipelines — Debezium, Fivetran, Airbyte and everything that follows the write-ahead log
- managed-service connectors and analytics sync jobs
- whatever a platform team set up years ago and nobody has audited since
Every one of those is an account, usually with credentials in a config file or a CI secret store, usually not treated as an administrative principal, often shared. PR:H describes the privilege level. It does not describe how many hands hold it.
And wal_level = logical is not an exotic setting. If you run any CDC at all, it is on.
Windows is the easy case
The exploitation path is materially different by platform, and this is worth knowing before you rank your fleet.
On Windows, an attacker can fetch the library over SMB from a machine they control. No file-write on the database host needed — just outbound 445 and a UNC path.
On Linux and macOS, they need somewhere to put the file first: existing file-write capability on the host, or NFS automounting enabled.
That difference is the whole risk assessment. A Windows PostgreSQL host with outbound SMB allowed and a CDC account in use is a materially worse position than the same setup on Linux.
The fix does not finish by itself
The patch introduces a new server parameter, output_plugin_libraries, which whitelists what may be loaded as a logical decoding output plugin. It defaults to pgoutput, test_decoding.
If you use any non-default output plugin — wal2json is the common one — the default whitelist will not include it, and your replication will break on restart until you add it. Update, set the parameter, then restart, in that order.
This is the second time in a week that a patch has needed a step after installation to actually help. The Switchvox fix had the same shape: shipping the update is not the same as being finished.
What to do
- Patch to 18.6, 17.11, 16.15, 15.19 or 14.24. Then set output_plugin_libraries for any non-default plugin before you restart.
- Enumerate who holds REPLICATION right now. Query pg_roles for rolreplication. Most estates will find accounts nobody can account for.
- Strip it from anything that does not need it. This is the mitigation with the longest shelf life; the next flaw in this area will need the same privilege.
- Restrict replication entries in pg_hba.conf to known addresses. REPLICATION plus an open host rule is the combination that matters.
- Block outbound SMB (445) and NFS (2049) from database servers, and disable autofs where it is not needed. On Windows especially, that outbound path is the exploit.
- Rank Windows hosts first.
Worth noting alongside this: two of the seven flaws CISA added to KEV this week were improper authentication in infrastructure nobody files under security software. The database is in that category too.
What is not established
- In-the-wild exploitation. None confirmed as of 4 September, and CVE-2026-6471 is not in CISA's KEV catalogue.
- How the two doors diverged. Nothing published explains why the replication parser skipped the LOAD path restriction in 2014.
- Whether any of the three persistence mechanisms in Cyera's PoC have been seen outside the lab.
- Whether managed PostgreSQL services are patched. Every provider is on its own schedule and most have not said.
Credited discovery: Vladimir Tokarev and Yu Kunpeng.
