A Backup Account Just Became a Root Shell
Cyera Research disclosed CVE-2026-6471 on September 1, and the name it gave the flaw, PostGREShell, describes exactly what it does. Any database account granted the REPLICATION attribute, the same privilege routinely handed to backup jobs, disaster-recovery tooling, and change-data-capture pipelines, can turn that access into full remote code execution on the underlying server. The account never needs superuser rights. It only needs the ability to create a logical replication slot, which is standard practice on any Postgres instance running CDC, a managed backup product, or a downstream analytics feed.
CVSS scored the bug 7.2, a number that understates the real blast radius once you account for how common REPLICATION grants actually are inside a typical enterprise data estate. Service accounts for backup software, streaming ETL jobs, and read replicas hold this attribute by default in countless environments, and almost none of them get the security review a superuser account would. That gap between assumed risk and actual privilege is the story here.
Twelve Years Hiding in Plain Sight
The vulnerability sat inside PostgreSQL's logical decoding subsystem since version 9.4 shipped in 2014, meaning every supported release for twelve years carried it. The feature lets a replication account choose which output plugin decodes the write-ahead log, and that plugin name was never validated against directory separators or absolute file paths. Researchers Vladimir Tokarev and Yu Kunpeng reported the issue to the PostgreSQL Security Team, which confirmed it on February 27, 2026.
Cyera argues Postgres today underpins financial transactions, medical records, government infrastructure, SaaS platforms, and AI and ML pipelines, well past the simple web-app backend most people picture when they hear the name. That framing matters for scale: Cyera's own research puts the affected install base at more than 39,000 organizations running self-managed Postgres, a population wide enough that a single unpatched replication account anywhere in the fleet is enough to matter, and diverse enough that the flaw touches regulated data of nearly every kind an enterprise holds. Twelve years is also long enough that the original engineering assumption behind the design, that only a trusted administrator would ever configure a decoding plugin, quietly stopped matching how modern data pipelines actually grant replication access to automated tooling.
How the Exploit Actually Works
Once an attacker holds a REPLICATION-capable account, they create a logical replication slot and point it at a plugin name that is really a file path. On Windows, a UNC path such as a share on an attacker-controlled server triggers an automatic SMB download of the malicious library. On Linux and macOS with NFS automounting enabled, a relative path traversal reaches the same kind of attacker-controlled network resource. Either way, the server fetches and loads code it never should have trusted, and it does so automatically the moment the replication slot is created, with no additional confirmation step standing between a low-privilege account and a loaded binary.
The plugin loads through dlopen or LoadLibrary directly into the PostgreSQL process, and its initialization function runs immediately with full server privileges. Cyera describes it plainly: 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. From there the attacker can rewrite the pg_authid catalog to grant permanent superuser, rewrite pg_hba.conf for passwordless access, and register in shared_preload_libraries so the backdoor survives a restart, giving a single exploited backup account a durable, self-reinstalling foothold on the server.
A Live Market for Malicious Plugins Already Existed
Cyera scanned VirusTotal and found 114 distinct malicious PostgreSQL output plugins already circulating in the wild, tagged as trojans, cryptocurrency miners, and reverse shells. That detail matters more than the CVE number itself, because it means attacker tooling for this exact class of abuse existed before Cyera's research made the underlying flaw public. Some fraction of that activity was almost certainly opportunistic exploitation of an undisclosed weakness rather than a reaction to a disclosure that had not happened yet, which is a very different threat model than the usual patch-Tuesday race against proof-of-concept code.
The lesson for security teams is that the absence of a public CVE never meant absence of exposure here, and the same logic applies to any database extension or plugin ecosystem that accepts loadable code from a lower-privilege account. Treat plugin-loading paths as an attack surface worth auditing on their own merits, independent of whatever the current patch calendar happens to flag as urgent this month, because the next unnamed version of this bug is unlikely to announce itself with a friendly disclosure timeline.
The Fix Nobody Noticed for a Month
PostgreSQL shipped the actual fix quietly inside its scheduled August 13 minor release, tagged as versions 18.6, 17.11, 16.15, 15.19, and 14.24. The PostgreSQL Global Development Group's own release notes state that previously a replication user could select any loadable library for logical decoding, allowing exploits of various sorts. A new configuration parameter, output_plugin_libraries, now restricts which plugins a replication account is permitted to load, defaulting to only the two safe built-ins, pgoutput and test_decoding, closing off the arbitrary-path behavior entirely for anyone who upgrades and takes the default.
That default has an operational consequence worth planning around: any shop using a custom decoding plugin, such as wal2json or Debezium's decoder, needs to explicitly allow-list it in the new parameter before upgrading, or replication will silently stop working the moment the upgrade completes. Cyera's public write-up on September 1 is what turned that routine point release into a headline seven weeks later, with Hacker News, SecurityWeek, and Security Affairs all covering it within three days of publication.
What This Means for Your Postgres Fleet
Postgres runs underneath Aurora, Cloud SQL, Azure Database for PostgreSQL, and a long tail of internal CDC pipelines across almost every enterprise stack we track, which means this is rarely a single-instance problem to fix. The practical move now is auditing every account holding the REPLICATION attribute across every managed and self-hosted instance you operate, restricting those connections to trusted IPs in pg_hba.conf, and adding the output_plugin_libraries entries your CDC tooling actually needs before flipping the new default on in production.
The disclosure timeline is worth sitting with too. PostgreSQL confirmed the bug privately in February, patched it in a routine August release, and it only became public knowledge in September through independent research rather than a coordinated vendor announcement. Treat every quarterly minor version bump on any open-source data infrastructure you run as a security event worth reading the changelog for line by line, not a maintenance checkbox your team defers until the next sprint has room for it.
