ZeroHour
CSO Onlinepublished ()ingested

Decade-old PostgreSQL flaw turns backup account into a backdoor

AI summary · glm-5.3-flash

Cyera disclosed CVE-2026-6471, a decade-old PostgreSQL flaw letting REPLICATION-attribute accounts achieve RCE and superuser compromise, patched August 13.

Cyera Research's 'PostGREShell' flaw exists in PostgreSQL's logical replication output plugin loading, where the replication code path never called the library-path security check, allowing path traversal or UNC paths to load arbitrary code. A low-privilege backup account can achieve code execution on Windows, Linux, and macOS, then escalate to superuser with persistent backdoor access. CVE-2026-6471 affects versions back to PostgreSQL 9.4 (2014) and was patched in releases 18.6, 17.11, 16.15, 15.19, and 14.24 on August 13. CVSS is 7.2, and no exploitation of this specific CVE has been confirmed, though VirusTotal hunting found 114 malicious PostgreSQL plugins.

  • Replication code path skips check_restricted_library_name(), enabling path traversal in plugin names
  • Code execution escalates to superuser with persistence via auth config and preloaded libraries
  • Windows hosts especially exposed via malicious DLLs on remote SMB servers
  • Patched in all supported branches including 18.6 and 14.24 on August 13, 2026
  • VirusTotal hunt found 114 malicious PostgreSQL plugins, though none tied to CVE-2026-6471
ProductsPostgreSQL
OrganizationsPostgreSQLCyera

Vulnerabilities mentionedAll →

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2026-6471
Missing Authorization in PostgreSQL Logical Decoding Lets REPLICATION Role Run Code

CVE-2026-6471 is a missing-authorization flaw (CWE-862) in PostgreSQL's logical decoding that does not restrict which decoding plugin a replication role may load. An attacker holding a database role with the REPLICATION privilege but without superuser rights can select an arbitrary logical decoding plugin, causing the server to dlopen any file visible to the operating-system account running PostgreSQL and thereby execute arbitrary code as that account. Successful exploitation gives code execution as the PostgreSQL service account (typically the 'postgres' OS user) on the database host, with high impact on confidentiality, integrity, and availability; related reporting indicates the flaw has existed for roughly 12 years and is commonly reached through backup or replication accounts. All deployments on PostgreSQL versions prior to 18.6, 17.11, 16.15, 15.19, and 14.24 are affected where non-superusers have been granted the REPLICATION privilege. No exploitation in the wild, public proof-of-concept, or CISA KEV listing is known; EPSS currently estimates a 0.3% probability of exploitation within the next 30 days.

Do: Upgrade to PostgreSQL 18.6, 17.11, 16.15, 15.19, or 14.24 depending on the branch in use. As interim mitigation, audit all roles holding the REPLICATION privilege, revoke it from users who do not need replication or logical decoding, and restrict which decoding plugins may be selected. Pay particular attention to backup and replication service accounts, which related reporting highlights as the likely abuse path.

7.2<1%
  • PostgreSQL All versions before 18.6 (18.x branch)
  • PostgreSQL All versions before 17.11 (17.x branch)
  • PostgreSQL All versions before 16.15 (16.x branch)
  • +2 more
massmillions of installations (PostgreSQL is deployed across millions of on-prem and managed-cloud database instances, though only hosts granting REPLICATION to…
Full article627 words · extracted from csoonline.com · click to collapse

A critical vulnerability in PostgreSQL had remained hidden for more than a decade, potentially turning a routine backup account into a path to full database and server compromise.

The issue, dubbed PostGREShell by Cyera Research, exists in the database’s replication functionality and could allow an attacker with a low-privilege account carrying the REPLICATION attribute to load and execute arbitrary code.

“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 vulnerability, tracked as CVE-2026-6471, affects PostgreSQL versions dating back to 9.4, released in 2014, and was patched in all supported PostgreSQL releases, including versions 18.6, 17.11, 16.15, 15.19, and 14.24, released on August 13.

While PostgreSQL installations across Windows, Linux, and macOS were affected, the conditions needed to achieve code execution vary by platform, Tokarev noted.

Existing protections were not enough

The problem comes from PostgreSQL’s handling of output plugins used by logical replication. These plugins are compiled code that PostgreSQL loads to format database changes for external systems and tools.

PostgreSQL already has protections designed to stop non-superusers from loading arbitrary libraries from unsafe filesystem locations. Its “check_restricted_library_name()” mechanism restricts 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 then 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.

The resulting code execution is serious especially because REPLICATION accounts are commonly used as operational plumbing for backups, replicas, change data capture pipelines, migrations, and monitoring.

Cyera said Windows systems are particularly exposed because an attacker could host a malicious DLL on a remote SMB server and point PostgreSQL at it, requiring no prior placement of the malicious file on the target system.

Backup accounts turned into superusers

The problem does not stop at code execution.

Because an output plugin runs inside the PostgreSQL server process, Cyera said malicious code can operate outside the normal SQL permission model. A malicious plugin could manipulate PostgreSQL internals to elevate the attacker’s privileges to superuser and modify internal authentication data.

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

Cyera demonstrated multiple persistence mechanisms, including modifications 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.

The company reported the issue to the PostgreSQL Security Team in February, which reviewed the findings, assigned the flaw a CVE ID, and released fixes in August.

Though the flaw fell short of a critical CVSS rating at 7.2, Cyera urged customers to patch immediately, noting that PostgreSQL plugins are a popular target for attackers. Its VirusTotal threat hunt found 114 malicious PostgreSQL plugins in the wild, including trojans, cryptocurrency miners, and reverse shells, though the disclosure did not link any of those plugins to the exploitation of CVE-2026-6471.

Outside of patching, users were recommended to audit accounts with the REPLICATION attribute, restrict replication access and block unnecessary outbound SMB and NFS connections from database servers.

Text extracted automatically; images, tables and formatting may be missing. Original: https://www.csoonline.com/article/4218101/decade-old-postgresql-flaw-turns-backup-account-into-a-backdoor.html