PostGREShell: a PostgreSQL flaw turns replication accounts into a launchpad for code execution

A vulnerability in PostgreSQL’s logical replication system allows an account with the REPLICATION attribute to load arbitrary code into the database server process. Tracked as CVE-2026-6471 and dubbed PostGREShell by Cyera, the flaw has a CVSS score of 7.2.

The attack does not require initial PostgreSQL superuser privileges. It does, however, require an account authorized for replication—a capability often granted to backup software, standby servers, pipelines, and monitoring platforms.

Once loaded, the malicious code runs with the privileges of the operating system account used by PostgreSQL. From there, it can also manipulate the database’s internal mechanisms, potentially granting permanent superuser privileges.

As of September 4, 2026, there is no information indicating that CVE-2026-6471 has been added to CISA’s Known Exploited Vulnerabilities catalog. No CISA remediation deadline is therefore known.

The weakness lies in the logical decoding plugin selection process

The vulnerability affects logical decoding, a feature used by logical replication to convert database changes into a stream that external applications can interpret.

When a client opens a logical replication session, it creates a replication slot and specifies which output plugin should process the events. PostgreSQL must then locate and load the corresponding library.

The problem is a missing authorization check, classified as CWE-862, Missing Authorization. A non-superuser with the REPLICATION attribute can specify an arbitrary file instead of an approved output plugin.

According to Cyera’s technical analysis, the protocol parser accepts several characters in the double-quoted plugin name that can be used to construct a path:

• forward and backslashes;
• periods;
• directory traversal sequences such as ../;
• UNC paths used in Windows environments.

The name reaches the loader without sufficient validation. An attacker can therefore pass a complete path to dlopen() instead of being restricted to the name of a library allowed by the configuration.

The payload is loaded into the same address space as the PostgreSQL process. No dedicated sandbox is involved, and the code can call the database’s internal APIs with the privileges of the running process.

An account should therefore not be considered trustworthy simply because it is not a superuser. In this scenario, REPLICATION becomes a code execution capability.

From in-process execution to modifying pg_authid

The initial impact involves the operating system account running PostgreSQL. A malicious library can read and modify anything accessible to that process and directly interfere with the database’s operation.

Cyera also described a path to obtaining PostgreSQL superuser privileges. The plugin can invoke internal functions to operate as the bootstrap superuser and directly modify pg_authid, the catalog containing sensitive account attributes.

By setting the relevant flags, an attacker can turn an existing identity into a permanent superuser. The compromise therefore does not remain confined to the replication session used to launch the attack.

These privileges enable a range of actions:

• access to tables in all hosted databases;
• modification of configurations, roles, and objects;
• reading private keys accessible to the PostgreSQL process;
• writing files to paths accessible to the operating account;
• executing commands on the operating system;
• installing persistence mechanisms.

Persistence may include enabling passwordless access, copying the payload to a stable location, and registering it to load into new backend processes. The code may also reapply privilege changes after an attempted recovery.

This makes simply revoking the compromised role insufficient. If a library has already been installed or registered, the operating system and PostgreSQL startup mechanisms must also be investigated.

Vulnerable versions and releases to install

The vulnerability affects PostgreSQL. The NVD description lists versions earlier than the following fixed releases as vulnerable, with each release applying to its respective branch:

PostgreSQL branch	First fixed version
18	18.6
17	17.11
16	16.15
15	15.19
14	14.24

SecurityWeek places the affected range between PostgreSQL 9.4 and 18 and reports that Cyera also verified the issue in version 18.2. The weakness is therefore present in releases distributed since 2014.

A summary line associated with the CVE record uses the narrower expression postgresql postgresql < 14.24. However, this conflicts with the advisory details, which explicitly list fixes for branches 15, 16, 17, and 18 as well.

For operational purposes, the following should therefore be treated as vulnerable:

• version 18 releases earlier than 18.6;
• version 17 releases earlier than 17.11;
• version 16 releases earlier than 16.15;
• version 15 releases earlier than 15.19;
• version 14 releases earlier than 14.24.

No specific fixed release is listed for branches 9.4 through 13. Organizations using them should account for this in their upgrade plans and avoid interpreting the absence of a listed patch as evidence that the vulnerability does not apply.

Why REPLICATION accounts are the primary target

The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. The attack is network-reachable, has low complexity, and does not require user interaction.

The PR:H requirement indicates that elevated privileges are needed. In the case of PostGREShell, however, this does not mean the attacker must already be a database administrator: they must control an account with the REPLICATION attribute.

These credentials may be present in backup systems, pipeline secrets, standby servers, or observability tool configurations. An organization may therefore have protected them less rigorously than accounts explicitly classified as administrative.

The impact extends to both on-premises deployments and databases reachable through corporate networks or cloud infrastructure. Exploitation still requires suitable credentials and the ability to start or use a logical replication session.

No specific indicators of compromise have been published, such as hashes, payload names, or network addresses. It is also not known whether the vulnerability is already being used in real-world attacks.

Update, audit roles, and look for anomalous loads

The primary mitigation is to install PostgreSQL 18.6, 17.11, 16.15, 15.19, or 14.24, depending on the branch in use. No official workaround has been provided as an alternative to patching.

Administrators should then inventory all accounts with REPLICATION and verify that the privilege is justified by a documented operational requirement. Where it is not needed, it should be removed.

Detection efforts should focus on:

• unusual creation or use of logical replication slots;
• replication sessions originating from unexpected addresses or systems;
• plugin names containing path separators, ../, or UNC paths;
• libraries loaded from unexpected directories;
• anomalous changes to roles and attributes stored in pg_authid;
• changes to authentication rules, including passwordless connections;
• new or modified files in directories accessible to the PostgreSQL process;
• configurations that cause libraries to be persistently loaded into new backend processes.

If signs of exploitation emerge, the response should not be limited to changing passwords. The database, the PostgreSQL operating account, and all secrets readable by that process should be treated as compromised.

Credential rotation should be accompanied by an examination of loaded libraries, modified files, superuser roles, and authentication settings. Only after this cleanup can the update close the attack vector without leaving previously installed persistence mechanisms active.