PostgreSQL Hit by 12-Year-Old Vulnerability Allowing Server Takeover
PostgreSQL flaw CVE-2026-6471, present since 2014, lets low-privilege replication accounts execute code and take over database servers; patches released.
Cyera researchers disclosed PostGREShell (CVE-2026-6471, CVSS 7.2), a missing-authorization bug in PostgreSQL logical decoding that lets users with REPLICATION privilege dlopen arbitrary files and execute code as the server account. The flaw affects PostgreSQL 9.4 through 18 and can yield privilege escalation, permanent superuser access and persistent backdoors on Windows, Linux and macOS. Fixes are available in versions 18.6, 17.11, 16.15, 15.19 and 14.24. Defenders should update and remove unnecessary Replication privileges.
- Bug existed in every PostgreSQL release since 2014 (9.4+)
- Replication accounts can load arbitrary plugins via dlopen()
- Enables RCE, superuser escalation and persistent backdoor access
- Fixed in 18.6, 17.11, 16.15, 15.19 and 14.24
- Review and restrict accounts holding REPLICATION privilege
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| 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% |
| massmillions of installations (PostgreSQL is deployed across millions of on-prem and managed-cloud database instances, though only hosts granting REPLICATION to… |
Full article611 words · extracted from securityaffairs.com · click to collapse
Pierluigi Paganini
September 04, 2026
PostGREShell (CVE-2026-6471) is a 12-year-old PostgreSQL flaw that lets low-privileged attackers execute code and take over servers.
Cyera researchers found a severe PostgreSQL vulnerability, dubbed PostGREShell and tracked as CVE-2026-6471 (CVSS score of 7.2). Present in releases dating back to 2014, the flaw can be exploited by attackers with low-level replication access to execute code, escalate privileges and gain permanent superuser access.
“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.” reads the advisory. “This in turn runs arbitrary code as that account. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.”
Attackers could also install a persistent backdoor in the database, potentially leading to a full takeover of the database and underlying server. PostgreSQL is widely used by enterprises worldwide.
PostgreSQL fixed CVE-2026-6471 in versions 18.6, 17.11, 16.15, 15.19, and 14.24.
The flaw is caused by missing authorization in PostgreSQL’s logical decoding feature. An attacker with “Replication” privileges could abuse a logical decoding plugin to load any file that the operating system account running PostgreSQL can access.
PostgreSQL uses a dedicated replication system to keep database replicas in sync for backup and recovery. To do this, backup tools, servers, data pipelines and monitoring systems are typically given an account with Replication privileges.
“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. That foothold escalates to full PostgreSQL superuser with persistent backdoor access, turning a routine replication account into total database and server compromise.” reads the report published by Cyera. “The vulnerability has existed in every PostgreSQL version since 2014 (9.4+) and was never patched until now.”
During logical replication, PostgreSQL records database changes as events that external tools can read. These tools create a logical replication slot and specify an output plugin, which PostgreSQL loads to format and deliver the changes.
When PostgreSQL loads a plugin, it runs the plugin’s initialization code with the same privileges as the database server. To prevent abuse, non-superusers are normally allowed to load plugins only from a directory controlled by an administrator.
PostgreSQL does not properly check the plugin name before passing it to the loader. This means an attacker could provide a full path to a file on the system. PostgreSQL then passes that path to dlopen(), the C/C++ function used to load shared libraries.
“When PostgreSQL loads the output plugin, the name from the user’s CREATE_REPLICATION_SLOTcommand is passed directly to the loader. No validation, no sanitization, no restriction check. The SQL LOADcommand, by contrast, passes a !superuser()flag that triggers the path validation. The replication path passes nothing. And the replication protocol’s parser accepts almost any character inside a double-quoted plugin name: slashes, backslashes, dots, ../ traversal, even Windows UNC paths.” Cyera states. “So an attacker can hand the loader a full filesystem path, and it reaches dlopen() (Linux/macOS) or LoadLibrary()(Windows) exactly as typed. The whole bug is code execution via dlopen().”
Once obtained, permanent superuser privileges, the attackers can access every table in every database, execute commands on the operating system, read private keys, and write files anywhere the PostgreSQL process can access.
PostGREShell can give attackers persistent backdoor access, including passwordless connections and restored superuser privileges. The flaw affects PostgreSQL 9.4–18.
Organizations should update their instances as soon as possible, review all Replication accounts, and remove the Replication attribute from accounts that do not need it.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, CVE-2026-6471)
Text extracted automatically; images, tables and formatting may be missing. Original: https://securityaffairs.com/198433/security/postgresql-hit-by-12-year-old-vulnerability-allowing-server-takeover.html