Security2 distinct publishers2 min readPublished
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
Compiled by The WatchSomething wrong?How this is made
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 [17].
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.
Ranked by verification strength, evidence, and original report placement.
Cyera researchers found a PostgreSQL vulnerability dubbed PostGREShell and tracked as CVE-2026-6471, with a CVSS score of 7.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.
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.
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.
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.
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.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 4, 2026
1 article · September 4, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
GitLab bundles a zero-click GraphQL flaw with a CSRF bug, and only one needs a victim1 distinct publisher
product
Nvidia's agent sandbox holds; the model server underneath it answers to any browser tab1 distinct publisher
security
Self-hosted ServiceNow operators inherit three unauthenticated CVSS 10.0 flaws to patch themselves2 distinct publishers
security
One shared-hosting customer can take root on a whole cPanel server through parked domains1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One vendor's research, quoted twice
Every technical detail here originates with Cyera. SecurityWeek and SecurityAffairs agree because neither checked anything — one quotes the impact narrative, the other quotes the code path. What raises this above a vendor blog post is the paperwork the project had to produce: a CVE, a severity score, and five named releases that either exist or do not. The researcher-only parts — reproduction on 18.2, the direct pg_authid write, the self-reloading plugin — stand entirely on Cyera's word.
Fix shipped, uptake unmeasured
The concrete fact is that patched builds exist across five branches, so remediation is available today. Past that the picture goes dark: no count of reachable instances, no telemetry on how many have upgraded, no inventory of Replication logins in the wild beyond Cyera's assertion that logical replication has become standard production plumbing. Footprint is asserted at 'tens of thousands of companies'; exposure is asserted at 'almost everywhere PostgreSQL runs'.
Takeover headlines over a 7.2
Both headlines promise server takeover; the 7.2 exists because you must already hold a Replication login, a precondition both publishers state plainly further down. Read either piece to the end and the framing is fair — read only the headline and you will overrate this. Pulling the other way, nobody flags that branches 9.4 through 13 sit inside the affected range with no fix named, which is a larger under-told fact than any overstatement on offer.
A named bug from a firm that sells data security
Cyera branded this PostGREShell, and branding is marketing; the firm sells data security, and 'the database behind much of the internet' is a sentence engineered to be quoted. Both outlets quoted it. Set against that, the disclosure went through the project's release process and the version numbers are falsifiable, which is what a researcher chasing credibility does rather than one chasing only attention. The publishers carry no visible stake beyond the traffic a takeover headline earns.
Confident about the bug, blank about your exposure
The mechanism, the affected range and the fixed builds are stated consistently enough across both accounts to act on this morning. The holes are identical in both: no independent reproduction, no word on exploitation, nothing for anyone running an unsupported branch. So the confidence attaches to the vulnerability, not to any estimate of who is actually reachable.