PostgreSQL backup accounts open 12-year backdoor

For more than a decade, a routine PostgreSQL backup account could have been the quiet entry point for a full database and server takeover. Researchers at Cyera have uncovered a critical vulnerability that sat hidden in the open-source database's replication functionality, waiting for an attacker with the right credentials to walk through.

The flaw, which Cyera dubs PostGREShell, turns a low-privilege account carrying the REPLICATION attribute into a launchpad for arbitrary code execution. The research, published on Cyera's blog, details how the vulnerability enables remote code execution on Windows, Linux, and macOS, and escalates to full PostgreSQL superuser access with persistent backdoor potential.

“The flaw lets a low-privilege “backup” account load and execute arbitrary code on the database server, achieving remote code execution across Windows, Linux, and macOS,” said Cyera researcher Vladimir Tokarev in a blog post. “That foothold escalates to full PostgreSQL superuser with persistent backdoor access, turning a routine replication account into total database and server compromise.”

The 12-year gap in replication

The vulnerability, formally tracked as CVE-2026-6471, traces back to PostgreSQL version 9.4, which arrived in 2014. The bug persisted through every release for over a decade until the PostgreSQL Security Team issued patches on August 13, which covered all supported branches.

The affected versions span the current supported spectrum: PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 all received fixes. The disclosure highlights that installations on Windows, Linux, and macOS were all vulnerable, though the specific conditions required to achieve code execution vary by platform, according to Tokarev.

This is not a niche corner of the database. Replication accounts are commonly used as operational plumbing for backups, replicas, change data capture pipelines, migrations, and monitoring. An attacker who already holds such credentials—perhaps obtained through other means—would find a direct path to far greater access.

Output plugins and a missed security check

At the heart of the issue is how PostgreSQL handles output plugins for logical replication. These plugins are compiled code that the database loads to format changes for external tools and systems. PostgreSQL has existing protections to stop non-superusers from loading arbitrary libraries from unsafe filesystem locations. Its “check_restricted_library_name()” mechanism limits where such users can load plugins from, preventing path traversal and absolute paths.

But, according to Cyera, the replication code path never called that security check. An attacker able to create a logical replication slot could provide a specially crafted plugin name containing filesystem paths, traversal sequences, or, on Windows, UNC paths. PostgreSQL would pass that name directly to the operating system’s library-loading functions.

When the malicious library was loaded, its initialization code would execute inside the PostgreSQL server process. On Windows, Cyera said the exposure is particularly acute: an attacker could host a malicious DLL on a remote SMB server and point PostgreSQL at it, without needing to place any file on the target system first.

From code execution to superuser

The damage does not stop at running arbitrary code. Because an output plugin operates within the PostgreSQL server process, malicious code can sidestep the normal SQL permission model entirely. A malicious plugin could manipulate PostgreSQL internals to elevate privileges to superuser and modify internal authentication data.

With superuser access, an attacker could reach all databases and their contents, including customer data, application secrets, and stored credentials. PostgreSQL superusers also interact with the underlying operating system, potentially allowing commands to be executed, sensitive files read, and data written to the server.

Cyera demonstrated multiple persistence mechanisms, including changes to PostgreSQL authentication configuration and the use of preloaded libraries that could survive database restarts. Tokarev said such access could also be used to gain deeper access into an organization’s environment.

Patch and audit replication accounts

The issue was reported to the PostgreSQL Security Team in February, which reviewed the findings, assigned a CVE ID, and released fixes in August. While the flaw earned a CVSS score of 7.2, which falls short of critical, Cyera still urged customers to patch immediately.

The urgency stems from the broader threat landscape. PostgreSQL plugins are a popular target for attackers. A VirusTotal threat hunt by Cyera found 114 malicious PostgreSQL plugins in the wild, including trojans, cryptocurrency miners, and reverse shells. However, the disclosure did not link any of those plugins to exploitation of CVE-2026-6471.

Beyond applying patches, Cyera recommended that organizations audit accounts with the REPLICATION attribute, restrict replication access, and block unnecessary outbound SMB and NFS connections from database servers.

Why it matters now

The 12-year window before this was discovered suggests that replication functionality has been a blind spot for security review. The fact that a low-privilege backup account is enough to trigger the flaw means that even environments with disciplined credential management could be at risk, especially since replication accounts are often treated as routine infrastructure rather than sensitive assets.

This could mean that organizations using PostgreSQL with logical replication should treat any replication account as a high-value target and prioritize auditing those credentials immediately. The availability of public proof-of-concept details in the Cyera research means that attackers now have a clear roadmap to weaponize this vulnerability, making timely patching and account review all the more critical.