Any PostgreSQL replication account can load a shared library as the postgres OS user
CVE-2026-6471 has sat in every PostgreSQL release since 9.4 shipped in 2014. Cyera says the plugin name in a replication slot request reaches dlopen() unvalidated, which makes the fix a privilege audit as much as a patch.
The Watch · Security desk
What happened
- Cyera disclosed CVE-2026-6471, which it calls PostGREShell: missing authorization in PostgreSQL logical decoding lets a non-superuser holding REPLICATION privilege run arbitrary code as the server's OS account.
- Every PostgreSQL release from 9.4 in 2014 through 18 carries the flaw, and Cyera says it was never patched until now.
- The plugin name from a CREATE_REPLICATION_SLOT request goes to dlopen() on Linux and macOS or LoadLibrary() on Windows exactly as typed, giving remote code execution on all three platforms.
- Once loaded, Cyera's plugin calls an internal function to become bootstrap superuser for the session, then writes to the pg_authid catalog table and flips every privilege flag to true.
- The same plugin installs persistence: passwordless connections, a copy of itself in a stable location, registration to reload into every new backend, and re-application of the superuser change if reverted.
Why it matters
- Who's exposed exposure The reachable surface is not the version list but the credential list: every backup tool, standby server, data pipeline and monitoring utility issued a Replication account is now a code-execution path into the database host.
- What it limits constraint Instances on branches 13 and older are inside the affected range with no patched release named, so for them the privilege review is the only control on offer.
- Who has to decide decision With update, account audit and attribute removal the only measures named, a deferred patch window forces a pick between leaving the path open and pulling REPLICATION off a service account that needs it to run.
- What it costs cost Patching an already-compromised instance does not reverse the catalog write, so any cluster with a suspect Replication account turns into forensics and rebuild work rather than a version bump.
Next story · Security · 3d ago
Installing MarkLogic's August fixes leaves 31 newer flaws openConfirmed2 publishers
Two call paths reach the same loader inside PostgreSQL, and only one of them is checked. Cyera is specific about the asymmetry: the SQL LOAD command passes a !superuser() flag that triggers path validation, and the replication path passes nothing [6]. Code that arrives that way runs in PostgreSQL's own address space, with no sandbox and no checks on internal API calls, because the server trusts anything it has loaded [9]. What that buys an attacker, according to Cyera, is every table in every database, OS command execution, private keys, and file writes anywhere the postgres process can reach [11].
The CVSS score is 7.2 [1]. The distance between that number and that outcome is the account requirement: the only precondition either account names is a login carrying the REPLICATION attribute, and REPLICATION is not superuser [19].
Neither published account specifies how the attacker's shared object gets onto a path the postgres account can read, which is the one step in the chain an operator can still interfere with. On Windows it may not have to be on the host at all, because Cyera says the replication protocol's parser accepts almost any character inside a double-quoted plugin name, including backslashes and UNC paths [7].
Neither Security Affairs nor SecurityWeek reports exploitation in the wild [18]. The argument for urgency is scope. Cyera's position is that logical replication is now standard production plumbing, so the vulnerable path exists almost everywhere PostgreSQL runs, and it confirmed the bug on 18.2 [5]. SecurityWeek puts the install base at tens of thousands of companies, large enterprises among them [15].
Closing it took five branch releases at once: 18.6, 17.11, 16.15, 15.19 and 14.24 [3][16]. Cyera's remediation order after the update is to review every Replication account and remove the attribute from the ones that do not need it [14]. That second step is per-role work, and it is not something a version scan produces for you.
What to watch
- Whether working exploit code appears publicly: Cyera has described the steps, and neither account reports released code.
- Managed PostgreSQL services are not addressed in either account, so watch for provider notices confirming the patched minor versions.
- Backports for branches out of support, including distribution-specific fixes for instances still on 9.4 through 13.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence74
- Adoption55
- Hype gap+24
- Incentives58
- Confidence72
Perspective Coverage
4 publishers- Builder
- Builder 32%
- Operator
- Operator 59%
- Investor
- Investor 9%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Cyera researchers found a PostgreSQL vulnerability dubbed PostGREShell and tracked as CVE-2026-6471, with a CVSS score of 7.2.
- [2]
The advisory states: 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, which runs arbitrary code as that account.
- [3]
Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19 and 14.24 are affected; CVE-2026-6471 was fixed in 18.6, 17.11, 16.15, 15.19 and 14.24.
- [4]
Cyera says the vulnerability has existed in every PostgreSQL version since 2014 (9.4 and later) and was never patched until now; the flaw affects PostgreSQL 9.4 through 18.
- [5]
Cyera says every version from 9.4 through 18 is affected, that it confirmed the flaw on 18.2, and that logical replication is now standard production plumbing, so the vulnerable path exists almost everywhere PostgreSQL runs.
- [6]
Cyera says the plugin name from the user's CREATE_REPLICATION_SLOT command is passed directly to the loader with no validation, sanitization or restriction check, while the SQL LOAD command passes a !superuser() flag that triggers path validation and the replication path passes nothing.
- [7]
Cyera says the replication protocol's parser accepts almost any character inside a double-quoted plugin name: slashes, backslashes, dots, ../ traversal, even Windows UNC paths.
- [8]
The supplied path reaches dlopen() on Linux and macOS or LoadLibrary() on Windows exactly as typed, achieving remote code execution across Windows, Linux and macOS.
- [9]
Cyera says code loaded via dlopen() runs in the same address space as PostgreSQL, with no sandbox and no checks on internal API calls, and the server simply trusts any code that was loaded.
- [10]
Cyera says the plugin calls an internal function to become the bootstrap superuser for the session, then writes directly to pg_authid, the catalog table defining who is a superuser, and flips every privilege flag to true.
- [11]
With permanent superuser privileges the attacker can access every table in every database, execute OS commands, read private keys, and write files to any location the postgres process can access.
- [12]
Cyera says the plugin can also deploy backdoor mechanisms: enabling connections without passwords, copying itself to a stable location and registering to be re-loaded into every new backend, and re-applying the superuser change even if it is reverted.
- [13]
PostgreSQL uses a dedicated replication protocol to sync replicas for backup and recovery; an account with the Replication attribute is required, and one is provided to any connected backup tool, server, pipeline and monitoring utility.
- [14]
Organizations are advised to update instances as soon as possible, audit their Replication accounts, and remove the Replication attribute from any account that does not need it.
- [15]
PostgreSQL is one of the most popular databases, used by tens of thousands of companies including large enterprises.
- [16]
The fix required five simultaneous branch releases.
- [17]
The named fixed releases cover branches 14 through 18 only, so affected branches 9.4 through 13 have no patched release named.
- [18]
Neither published account reports exploitation of CVE-2026-6471 in the wild.
- [19]
The only precondition named in either published account is a login holding the REPLICATION attribute; superuser is explicitly not required.
Sources
4 independent publishers whose own reporting we read for this story.
- scworld.comPostGREShell vulnerability allows server takeover
1 article · September 4, 2026
- securityaffairs.comPostgreSQL Hit by 12-Year-Old Vulnerability Allowing Server Takeover
1 article · September 4, 2026
- securityweek.com12-Year-Old PostgreSQL Vulnerability Enables Database, Server Takeover
1 article · September 4, 2026
- thehackernews.comPostgreSQL Fixes 12-Year-Old Logical Decoding Flaw Enabling Replication-Role Code Execution
2 articles · September 5, 2026
Topics and entities
Topics
- Vulnerability Disclosure
- Database Security
- Remote Code Execution Surfaces
- Logical Replication
Entities
- PostgreSQL Global Development Group
- CISA Known Exploited Vulnerabilities Catalog
- Vladimir Tokarev
- Cyera
- PostgreSQL