A Backdoor Sat Unnoticed in PostgreSQL's Backup Accounts for 12 Years, Turning the Database Behind Netflix, Instagram, and Uber Into an Open Door

Start with the account nobody thinks twice about, because that's exactly where this one lives. Security firm Cyera disclosed CVE-2026-6471, nicknamed PostGREShell, a vulnerability sitting in PostgreSQL's logical replication feature since it was introduced in version 9.4, back in 2014 — meaning this flaw has been quietly present in production databases for twelve years before anyone found it. PostgreSQL is the world's most widely used open-source relational database, and Cyera puts the exposed footprint at more than 39,000 companies, including names like Netflix, Instagram, Spotify, and Uber, though there's no indication any of those specific companies were actually targeted — the number describes scale of potential exposure, not confirmed victims.

The mechanism is worth understanding precisely, because the root cause is a genuinely uncomfortable one: PostgreSQL simply never validated what it was being asked to load. Every PostgreSQL deployment includes accounts carrying the "Replication" privilege — used constantly and unremarkably by backup tools, standby database setups, change-data-capture pipelines, migration tooling, and monitoring utilities. When one of those accounts requests logical decoding, it names an output plugin for PostgreSQL to load and run with the full privileges of the server process itself. Cyera's research found that PostgreSQL passed that plugin name straight to its loader with no validation and no sanitization at all — meaning an account that was only ever supposed to read replication data could instead point PostgreSQL at any file visible to the operating system account running the server and have it loaded and executed as code. Cyera's own framing of the flaw is the clearest summary available: "PostGREShell turns the Replication credential nobody worries about into code execution, superuser, and a persistent backdoor on the database behind much of the internet." From that single foothold, an attacker escalates to full PostgreSQL superuser and can install a backdoor engineered to survive routine cleanup — passwordless connections and restored superuser access that persist even after an administrator thinks they've locked things back down.

The disclosure timeline itself is a genuinely well-run example of responsible coordination, and worth noting precisely because it's the part that often gets skipped in coverage of a scary-sounding bug. Cyera privately reported the flaw, and the PostgreSQL Security Team — with named credit to security researcher Noah Misch — reviewed, confirmed, and coordinated a fix through the project's standard security release process, publishing patched versions on August 22: PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24. The fix itself is a plugin allowlist rather than the stricter directory-based restriction PostgreSQL normally applies to library loading, and that choice has a real, immediate operational consequence worth flagging directly: any environment using third-party logical decoding plugins outside PostgreSQL's own bundled set — tools like wal2json, decoderbufs, or proprietary change-data-capture plugins — will fail to initialize replication slots after patching, until those specific plugins get added to the new allowlist. If your organization runs PostgreSQL with any non-standard replication tooling, read the release notes before patching in production, not after something breaks at 2am. Cyera's own threat-hunting on VirusTotal separately turned up 114 malicious PostgreSQL plugins already circulating in the wild — trojans, cryptocurrency miners, and reverse shells — though the firm was careful to note none of those were confirmed tied to actual exploitation of this specific CVE. The practical guidance is direct: patch to the fixed version, and separately audit every account currently holding the Replication attribute, removing it from any account that doesn't genuinely need it — since the whole vulnerability class runs through a privilege most database administrators never think to question in the first place.

There's a broader pattern worth naming, because Cyera's own writeup draws the comparison explicitly: PostGREShell is the latest instance of a vulnerability shape that keeps recurring across major software — a server accepts a plugin or module name from a less-privileged caller, doesn't validate it, and loads it with full privileges regardless. Redis's MODULE LOAD command has powered multiple botnet campaigns through exactly this same shape of flaw. The lesson generalizes past PostgreSQL specifically: any system where a lower-privilege account can specify what gets loaded into a higher-privilege process is worth a second, skeptical look, regardless of how long that mechanism has existed without incident — twelve years of quiet operation was never evidence PostgreSQL's plugin loading was safe, it was just evidence nobody had looked closely enough yet.

---

Week in review: August 31–September 6

Since it's Sunday, here's what actually mattered across the full week.

The week opened with OpenAI confirming its upcoming Astra model had crossed the company's own "Critical" cybersecurity capability threshold — the first OpenAI model to do so, after independently building a full sandbox-escape exploit chain against a hardened browser and finding a privilege-escalation path from unprivileged user to root in a hardened OS, entirely without human intervention during evaluation. OpenAI paired that disclosure with real, costed safeguards: limited initial access through its Daybreak Blue defensive program, a two-week pause on reinforcement learning training for other in-development models, and direct testing partnerships with government agencies and external safety organizations. Days later, a genuinely balanced companion story landed from a different direction: Forescout's Vedere Labs published an honest account of using Claude to port a working PLC exploit between two WAGO controller models — real capability demonstrated, but also eight and a half hours of work, $535 in API costs, and a target device permanently bricked during a follow-up attempt, a useful corrective against treating either capability or risk in absolute terms.

Vulnerability disclosures ran heavy all week. SonicWall confirmed its third distinct SMA1000 zero-day attack chain in under a year, this one a maximum-severity, unauthenticated SSRF letting an attacker turn the appliance into its own proxy. Shadowserver separately found nearly 22,000 Microsoft Exchange servers still unpatched against a critical authentication-bypass flaw a full month after Microsoft shipped the fix. Cisco disclosed a maximum-severity, unauthenticated root-code-execution bug in Nexus 9000 switches with no fixed-release table published as of this writing, bundled alongside seven critical IOS XR vulnerabilities affecting every release with no available workaround. Google shipped its sixth actively exploited Chrome zero-day patch of the year, a V8 type confusion flaw reaching the roughly three billion people who use the browser, independently tracked by the Netherlands' own National Cyber Security Centre. And an AI-abuse story broke too: a ransomware crew's exposed infrastructure revealed the operator using SpaceX's Cursor AI coding assistant during live intrusions against more than 20 organizations, not by defeating its safety guardrails but simply by claiming the work was an authorized security test.

On the breach side, Thomson Reuters disclosed that an intruder spent months inside its West Publishing C-Track court case management platform, exposing Social Security numbers and in some cases sealed or confidential court records across 11 U.S. states, the U.S. Virgin Islands, and three Ontario courts — a clean illustration of third-party data liability reaching people who never chose to give the vendor their information at all. And closer to home for this site specifically, the pro-Russian hacktivist group Server Killers escalated its ongoing campaign against Norway, taking down multiple university websites and the shared education-sector IT provider Sikt on September 2 — the second distinct wave of a campaign that began in August over Norway's renewed defense cooperation with Ukraine, with no indication it's finished.

Pull the week together — Astra, Forescout's PLC experiment, SonicWall, Exchange, Cisco, Chrome, Aurora's Cursor abuse, Thomson Reuters, Server Killers, and now PostGREShell — and the same shape keeps repeating with almost no exceptions: known, exploitable weaknesses in infrastructure organizations already trust, sitting open far longer than anyone realized, or exploited faster than patch cycles are built to keep up with. Nothing this week needed a genuinely novel category of attack. It needed defenders checking the credentials and privileges nobody thinks to question — a replication account, an AI agent's stated justification, a browser tab, a vendor's vendor — because that's precisely where this week's attackers kept finding their way in.