12-Year-Old PostgreSQL Flaw Lets Attackers Execute Code on Database Servers

A newly disclosed PostgreSQL vulnerability, tracked as CVE-2026-6471 and nicknamed PostGREShell, could allow attackers with low-level replication access to execute arbitrary code on database servers.

The flaw in PostgreSQL logical decoding existed for roughly 12 years and has now been fixed in supported releases. PostgreSQL is widely used to store business data, application records, customer details, financial information, and cloud workloads.

The vulnerability is especially concerning because it affects an account type commonly used for backups, replication, disaster recovery, and change data capture operations.

The issue affects non-superuser PostgreSQL accounts that have the REPLICATION attribute. These accounts are typically used to support database replication, allowing standby servers and backup systems to receive database changes from the primary server.

However, researchers found that a replication-enabled account could abuse the logical decoding feature to force PostgreSQL to load an attacker-controlled library.

Logical decoding lets external tools read database changes from PostgreSQL’s write-ahead log. It uses output plugins to format those changes for replication, analytics, migration, and data pipeline tools.

12-Year-Old PostgreSQL Vulnerability

In vulnerable versions, PostgreSQL did not properly restrict the library path provided as an output plugin name. As a result, an attacker with REPLICATION privileges could point PostgreSQL to a malicious shared library available to the operating system account running the database.

PostgreSQL would then load the file using operating-system library-loading functions such as dlopen() on Linux and macOS or LoadLibrary() on Windows. The malicious code would execute with the permissions of the PostgreSQL server process.

This is important because the attacker does not need PostgreSQL superuser rights to begin the attack. A low-privileged replication account could become the entry point for code execution on the database server.

From there, attackers may attempt to access sensitive databases, steal credentials, alter account permissions, install persistent backdoors, or move deeper into the environment.

Cyera Research discovered CVE-2026-6471, a flaw dating to PostgreSQL 9.4’s 2014 release that stems from inadequate library-path restrictions in the logical replication workflow.

The PostgreSQL project has released patches for the vulnerability. Organizations should upgrade to PostgreSQL 18.6, 17.11, 16.15, 15.19, or 14.24, depending on the version branch they use. Versions earlier than these patched releases are affected.

Administrators should also audit all accounts with the REPLICATION attribute and remove the privilege from accounts that do not absolutely need it. Replication connections should be limited through strict pg_hba.conf rules and trusted source IP addresses.

Database teams should review logical replication activity for unusual attempts to create replication slots or suspicious plugin names that contain filesystem paths, traversal strings, or unexpected library names.

Restricting unnecessary outbound network access from database servers, especially SMB and NFS traffic, can also reduce the risk of remote library delivery paths.

CVE-2026-6471 shows that operational database accounts can become high-impact targets. A backup credential may appear low-risk, but in this case it could provide a path to code execution and a full compromise of a PostgreSQL environment.

Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.