A PostgreSQL replication account is privileged, but it was not supposed to choose an arbitrary native library and make the database server load it.

CVE-2026-6471, named PostGREShell by Cyera Research, closes that authorization gap in PostgreSQL logical decoding. The flaw can turn an already compromised replication role into code execution as the operating-system account running PostgreSQL.

TL;DR

  • PostgreSQL rates CVE-2026-6471 as high severity with CVSS 7.2, not critical.
  • Exploitation requires a role with the REPLICATION attribute; practical logical-decoding paths also depend on relevant server configuration and reachability.
  • Versions before 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
  • The August 13 updates introduce an allowlist for logical-decoding output libraries.
  • As of September 4, public reporting found no CISA KEV entry or public proof of concept. Patch promptly, but do not claim active exploitation without evidence.

Why Replication Can Load Code

Logical decoding converts PostgreSQL’s write-ahead log into a format consumers can process. A client creates or uses a replication slot and selects an output plugin, implemented as a shared library on the server.

Before the fix, PostgreSQL did not adequately restrict which library a non-superuser holding REPLICATION could name. If the operating-system account running PostgreSQL could see a chosen library, the server could load it with dlopen() and execute its initialization code.

Compromised REPLICATION role
        -> logical-decoding request names a plugin
        -> PostgreSQL resolves a server-visible library
        -> database process loads native code
        -> code runs as the PostgreSQL operating-system account

This is not unauthenticated internet RCE. The attacker first needs a valuable database credential or another way to issue replication-protocol requests. That prerequisite explains the official CVSS privileges-required rating. It does not make the outcome small: native code execution crosses the boundary between database permissions and the host operating system.

Separate the Confirmed Bug From the Research Claims

PostgreSQL confirms the missing authorization, affected versions, code-execution outcome, and fixed releases. Cyera says the behavior dates to the introduction of logical decoding in PostgreSQL 9.4 in 2014 and demonstrates paths across Linux, Windows, and macOS.

Cyera also reports finding 114 malicious PostgreSQL plugin binaries in VirusTotal. That is evidence that malicious plugins exist, not evidence that those samples exploited CVE-2026-6471 or that PostGREShell is active in the wild. Treating the two statements as equivalent would manufacture an exploitation claim the sources do not support.

Patch and Check the Privilege Boundary

Upgrade to PostgreSQL 18.6, 17.11, 16.15, 15.19, or 14.24 as appropriate. PostgreSQL’s release adds output_plugin_libraries, restricting which libraries logical decoding may load. Test legitimate change-data-capture and replication consumers after the update because third-party plugins may need to be explicitly allowed.

Inventory roles with rolreplication enabled:

SELECT rolname, rolsuper, rolreplication, rolcanlogin
FROM pg_roles
WHERE rolreplication OR rolsuper
ORDER BY rolname;

For each result, identify its owner, client systems, source addresses, authentication method, and last legitimate use. Remove REPLICATION from roles that do not require it. Restrict replication connections in pg_hba.conf to known identities and networks rather than treating a password as the only boundary.

What to Hunt For

Review replication-slot creation and logical-decoding activity against the plugins your environment actually uses. Investigate unknown shared libraries in PostgreSQL library paths, unexpected database-service child processes, new outbound connections from database hosts, and changes to startup or extension configuration.

On the identity side, look for replication accounts connecting from new IP addresses, interactive use of automation credentials, authentication outside scheduled backup or CDC windows, and a sudden shift from normal replication behavior to catalog or filesystem discovery.

If code execution is plausible, preserve the host and investigate it as an operating-system compromise. Dropping the suspicious database role alone does not remove native persistence.

Defensive Plan: Constrain the Replication Boundary

OwnerActionWhy it interrupts the attackHow to verify it worked
DBA teamInventory the exact server version and every role with rolreplication or superuser capability across self-managed servers, containers, and managed databases. Assign an owner and expected client to each role.CVE-2026-6471 requires replication privilege. Removing unused roles eliminates the prerequisite instead of relying only on exploit detection.Compare the query results above with backup and CDC inventories. Every remaining role has an owner, purpose, source, authentication method, and recent legitimate use.
Database platform ownerUpgrade to 18.6, 17.11, 16.15, 15.19, or 14.24 as applicable and configure output_plugin_libraries for only the plugins the environment needs.The fixed release adds the missing library restriction. An explicit allowlist prevents a replication client from choosing an arbitrary server-visible library.Run SELECT version(); and SHOW output_plugin_libraries; on each server, then test every approved CDC or replication consumer and confirm an unlisted test plugin is rejected.
Network securityRestrict replication entries in pg_hba.conf and network controls to named clients and required TLS identities. Deny unnecessary database-host egress, including SMB and NFS where they are not operationally required.Stolen replication credentials are less useful when they cannot connect from attacker infrastructure or make the server resolve a remotely hosted library path.Test the approved client successfully, then test the same role from an unapproved address and an unapproved outbound destination. Both negative tests must fail and log the decision.
SOC and DBA monitoringBaseline replication slots, output plugins, source addresses, schedules, and account use. Alert on first-seen plugins, slot creation outside change windows, interactive use of automation roles, and replication logins from new sources.The exploit path must exercise unusual replication behavior before native code runs. Baselines turn that required behavior into a detection opportunity.Compare pg_replication_slots and connection logs with the approved inventory; generate a benign test slot in a lab and confirm the alert contains role, source, slot, and plugin.
Host platform teamMonitor PostgreSQL library directories and service configuration for unexpected files or changes, and alert when the database service launches unusual child processes or opens new outbound connections.Successful exploitation crosses from database authorization into operating-system execution. Host telemetry catches the impact even if database logging is incomplete.Perform an authorized file-integrity test and benign child-process test in a lab; confirm the EDR or FIM alert identifies the PostgreSQL service as the parent or affected path.
Incident responseIf an unknown plugin was loaded or host execution is plausible, isolate the server, preserve database and host evidence, rotate replication and application credentials, and rebuild from trusted artifacts.Revoking the database role does not remove a native library, host persistence, or credentials already read by code running as the database OS account.Before restoration, document evidence hashes and credential revocation. After rebuild, compare packages, libraries, configuration, roles, and slots with the approved baseline.

Close remediation only when the fixed version is running, approved replication still works, unapproved sources and plugins fail, and pre-patch replication activity has been reviewed.

PostGREShell is serious because a trusted operational role crossed into native code execution. Its prerequisites are also exactly where defenders can reduce risk: fewer replication identities, narrower network paths, and an explicit plugin allowlist.

Sources