PostgreSQL PostGREShell Vulnerability CVE-2026-6471 Allows Arbitrary Code Execution

Critical PostgreSQL Security Flaw Affects Replication Users Across Versions 9.4 and Later

PostgreSQL has released security updates to address a long-standing vulnerability that could allow an attacker with a PostgreSQL account holding the REPLICATION attribute to execute arbitrary code with the privileges of the operating-system user running the database server.

Tracked as CVE-2026-6471, the vulnerability has a CVSS score of 7.2 and has existed since PostgreSQL 9.4, when logical decoding was introduced in 2014.

The vulnerability, referred to as PostGREShell by Cyera Research, affects PostgreSQL versions before 18.6, 17.11, 16.15, 15.19, and 14.24.

PostgreSQL CVE-2026-6471 Explained

The vulnerability is related to the way PostgreSQL handles logical decoding output plugins.

An account with the REPLICATION attribute can create replication slots and specify an output plugin. Before the security fix, PostgreSQL did not properly restrict which libraries could be loaded through this replication path.

As a result, an attacker who already has a sufficiently privileged replication account could potentially force PostgreSQL to load an attacker-controlled library.

Successful exploitation can result in arbitrary code execution as the operating-system account running PostgreSQL, commonly the postgres user.

Why CVE-2026-6471 Is Dangerous

The REPLICATION attribute is commonly assigned to infrastructure that needs access to PostgreSQL replication functionality.

Potentially affected environments can include:

  • Backup systems
  • Standby and replica servers
  • Change Data Capture (CDC) pipelines
  • Database monitoring systems
  • Replication management tools
  • Third-party PostgreSQL integrations

An attacker who compromises one of these replication credentials could potentially move from database-level access to operating-system-level code execution.

How the PostGREShell Attack Works

According to Cyera Research, the plugin name supplied through CREATE_REPLICATION_SLOT can reach PostgreSQL's library-loading functionality.

The existing PostgreSQL restrictions designed to control library loading by non-superusers were not applied in the same way to the replication path.

The replication protocol also permits characters such as path separators and directory traversal sequences inside quoted plugin names.

This means an attacker could potentially provide a path to a library outside the normal administrator-controlled plugin directory.

Once the malicious library is loaded, its code executes inside the PostgreSQL backend process with the privileges of the database server's operating-system account.

Remote Library Loading Scenarios

Cyera demonstrated different exploitation scenarios depending on the operating system and server configuration.

On Windows, an attacker can potentially abuse SMB network paths to make the PostgreSQL server retrieve a malicious library from infrastructure controlled by the attacker.

On Linux and macOS, exploitation through a remote filesystem requires configurations such as NFS automounting. Otherwise, an attacker would generally need another method to place a malicious library onto the database server.

This means exploitation is dependent on the attacker's existing access and the target environment's configuration.

PostgreSQL Security Fix

PostgreSQL addressed the vulnerability by introducing a new configuration parameter called:

output_plugin_libraries

The parameter acts as an allowlist for logical decoding output plugins.

By default, PostgreSQL allows:

pgoutput, test_decoding

After upgrading, installations using other logical decoding plugins must explicitly add those plugins to the allowlist.

PostgreSQL explained that the change was designed to prevent replication users from loading arbitrary libraries while avoiding unnecessary breakage for legitimate third-party output plugins.

Third-Party Plugins May Require Configuration Changes

Organizations using third-party logical decoding plugins may need to update their PostgreSQL configuration after installing the security update.

Examples include:

  • wal2json
  • decoderbufs

Administrators should identify the output plugins currently being used before upgrading.

A query provided in the security guidance is:

SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;

Administrators can then add required non-default plugins to output_plugin_libraries and reload the PostgreSQL configuration.

A full database restart is not required for this configuration change.

Affected PostgreSQL Versions

The following PostgreSQL versions are affected and should be upgraded:

PostgreSQL BranchFixed VersionPostgreSQL 1818.6PostgreSQL 1717.11PostgreSQL 1616.15PostgreSQL 1515.19PostgreSQL 1414.24

Organizations running older unsupported PostgreSQL releases should evaluate their upgrade path because the official advisory covers supported branches.

Organizations should prioritize the following actions:

1. Identify Replication Accounts

Review PostgreSQL roles that have the REPLICATION attribute and determine whether each account still requires it.

2. Check Logical Replication Slots

Run:

SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;

This can help identify output plugins currently associated with replication slots.

3. Upgrade PostgreSQL

Install one of the fixed versions:

  • 18.6
  • 17.11
  • 16.15
  • 15.19
  • 14.24

Organizations using vendor-specific PostgreSQL packages should also install the corresponding security update.

4. Configure the Output Plugin Allowlist

If the environment uses third-party logical decoding plugins, add the required libraries to:

output_plugin_libraries

Then reload the PostgreSQL configuration.

5. Review pg_hba.conf

Restrict replication connections to trusted source addresses and networks.

Replication access should not be unnecessarily exposed to untrusted networks.

6. Restrict REPLICATION Privileges

Remove the REPLICATION attribute from accounts that do not require replication functionality.

7. Restrict Outbound Network Access

Where practical, restrict database servers from making unnecessary outbound connections.

Cyera specifically recommends considering controls around:

  • SMB traffic on TCP port 445
  • NFS traffic on TCP port 2049

8. Review NFS and Automount Configuration

Organizations that do not require NFS automounting should consider disabling it to reduce potential attack paths.

PostgreSQL Upgrade Compatibility Consideration

The new security control can affect existing deployments.

Administrators should configure output_plugin_libraries before running:

pg_upgrade --check

when migrating from PostgreSQL 17 or later if the previous cluster uses non-default logical decoding plugins.

Otherwise, the upgrade check may fail because the old cluster's replication slot plugins are not permitted by the new configuration.

Additional Issue Identified in pg_createsubscriber

A separate usability issue remains around pg_createsubscriber.

The utility can create replication slots using pgoutput without first checking whether that plugin is permitted by the new output_plugin_libraries setting.

As a result, a dry run can succeed while the actual conversion later fails.

A patch addressing this behavior was reportedly still under review as of September 4, 2026.

Is CVE-2026-6471 Being Actively Exploited?

According to the information available in the supplied report, CVE-2026-6471 was not listed in CISA's Known Exploited Vulnerabilities catalog as of September 4, 2026.

The report also states that no public proof-of-concept code was identified in public repositories at that time.

However, the vulnerability should still be treated as a significant database security issue because successful exploitation can result in operating-system-level code execution.

Key Takeaways

CVE-2026-6471 is a long-standing PostgreSQL logical decoding vulnerability that can turn a compromised REPLICATION account into potential operating-system-level code execution.

The most important actions for defenders are:

  • Upgrade PostgreSQL to a fixed release.
  • Audit accounts with the REPLICATION attribute.
  • Review replication slots and logical decoding plugins.
  • Configure output_plugin_libraries correctly.
  • Restrict replication access through pg_hba.conf.
  • Remove unnecessary REPLICATION privileges.
  • Review SMB and NFS exposure from database servers.
  • Monitor PostgreSQL logs for suspicious library-loading attempts.

Organizations using PostgreSQL for CDC, backups, replication, monitoring, or database synchronization should prioritize reviewing their exposure to this vulnerability.