PostGREShell: A 12-Year-Old PostgreSQL Vulnerability Turns REPLICATION Access into RCE

Researcher Vladimir Tokarev from Cyera Research disclosed details of CVE-2026-6471 (PostGREShell), a PostgreSQL vulnerability that has existed since version 9.4 (2014). It allows an account with the REPLICATION privilege to load an arbitrary library and execute code in the PostgreSQL process.

The issue lies in the logical decoding mechanism. When creating a logical replication slot, the client specifies an output plugin—a compiled library (.so, .dll, .dylib) that PostgreSQL loads into its process. For the SQL LOAD command, PostgreSQL restricts library loading through check_restricted_library_name(). However, this check was not performed in the replication path: the output plugin name was passed directly to the loader, while the replication protocol parser accepted path components including /, \, ../, and even Windows UNC paths. As a result, an attacker can specify a path to their own library and have it loaded via dlopen() or LoadLibrary().

On Windows, the attack can be fully remote if the following conditions are met: • A PostgreSQL account with REPLICATION; • wal_level = logical; • Outbound SMB/445 connectivity from the server to the attacker. A UNC path such as \\attacker\share\evil.dll can be specified as the plugin. When PostgreSQL calls LoadLibrary(), Windows connects to the attacker's SMB server and loads the DLL directly into the PostgreSQL process — nothing needs to be placed on the target filesystem beforehand.

On Linux/macOS, a similar scenario is possible through NFS when /net automount is active. In typical Linux/Docker/Kubernetes environments, the attacker additionally needs a way to write a .so file to a filesystem accessible to PostgreSQL.

The loaded code executes with the privileges of the postgres system user. In their PoC, the researchers use an internal PostgreSQL function to become the bootstrap superuser for the current session, then directly modify pg_authid to make PostgreSQL superuser privileges persistent.

The vulnerable path was introduced with logical decoding in PostgreSQL 9.4 and remained exposed for approximately 12 years. Cyera also found 114 malicious PostgreSQL plugins on VirusTotal, including trojans, cryptocurrency miners, and reverse shells. However, this does not prove that CVE-2026-6471 has been exploited in real-world attacks.

To mitigate the vulnerability, install the PostgreSQL security update, audit accounts with REPLICATION, remove the privilege where it is not strictly required, restrict the remaining accounts to known trusted IPs via pg_hba.conf, and block unnecessary outbound SMB/445 and NFS/2049 traffic from PostgreSQL servers.

Article: https://www.cyera.com/research/postgreshell-the-database-powering-much-of-the-internet-had-an-open-door-for-12-years