A critical PostgreSQL vulnerability dubbed PostGREShell could allow low-privileged backup and replication accounts to execute arbitrary code, escalate to database superuser privileges, and establish persistent access on vulnerable servers.
Tracked as CVE-2026-6471, the flaw was discovered by Cyera Research and affects PostgreSQL versions dating back to 9.4, released in 2014. PostgreSQL addressed the issue in its August 22, 2026 security release, ending a vulnerability window that spanned roughly 12 years.
The bug exists in PostgreSQL’s logical replication mechanism, which is commonly used for backup operations, standby databases, change data capture pipelines, migrations, monitoring, and analytics.
12-Year-Old PostgreSQL Flaw
Organizations often assign the REPLICATION attribute to service accounts so they can access write-ahead log data without granting full database administrator permissions.
However, Vladimir Tokarev found that replication users could abuse the CREATE_REPLICATION_SLOT workflow to specify a malicious logical output plugin. PostgreSQL loads these plugins as compiled shared libraries, including .so files on Linux, .dll files on Windows, and .dylib files on macOS.
When a plugin is loaded, its initialization code executes inside the PostgreSQL server process. This normally dangerous functionality is protected in the SQL LOAD command through a restricted-library-name validation mechanism.
According to Vladimir Tokarev, that validation was missing from the replication protocol path. As a result, an attacker could provide plugin paths containing directory traversal sequences, absolute paths, backslashes, or Windows UNC paths.
The database server would then pass the supplied location to the operating system’s library loader, potentially allowing attacker-controlled code to run with the privileges of the PostgreSQL server process.
The practical impact varies by platform. On Windows, an attacker may be able to host a malicious DLL on an SMB share and instruct PostgreSQL to load it remotely through a UNC path.
Linux and macOS systems with NFS automounting enabled could also face remote library-loading scenarios. In other environments, exploitation may require the attacker to first place a malicious shared library on the target system.
Once arbitrary code runs within the PostgreSQL process, the attacker can bypass the database’s SQL permission model.
The research describes how a malicious plugin could alter internal privilege data, elevate an account to superuser status, and modify authorization behavior without relying on standard SQL permission checks.
A PostgreSQL superuser can access data across databases, read files available to the database process, write files, and execute operating-system commands through supported administrative features.
Researchers also warned that attackers could create multiple persistence mechanisms, including changes to pg_hba.conf, malicious shared_preload_libraries entries, and reapplication of unauthorized superuser privileges.
Administrators should immediately apply PostgreSQL’s security update and review all accounts assigned the REPLICATION attribute. Replication access should be limited to essential accounts and trusted source IP addresses through tightly controlled pg_hba.conf rules.
Security teams should also block unnecessary outbound SMB traffic on port 445 and NFS traffic on port 2049 from database servers. Monitoring should flag unexpected replication-slot creation attempts, unusual plugin names, and plugin paths containing /, \, or ...
The vulnerability highlights how operational backup credentials can become high-impact attack paths when plugin-loading functionality is not consistently protected across every server interface.
Give your security team the visibility and context to investigate suspicious activity faster and contain threats before business impact grows. Strengthen Your Investigations with ANY.RUN
