GBHackers

12-Year-Old PostgreSQL Flaw Lets Attackers Execute Code and Take Over Database Servers


A critical PostgreSQL vulnerability dubbed PostGREShell could allow low-privileged replication accounts to execute attacker-controlled code, escalate to database superuser, and establish persistent backdoors on affected servers.

Tracked as CVE-2026-6471, the flaw reportedly affected PostgreSQL releases from version 9.4 onward, leaving a dangerous plugin-loading path exposed for roughly 12 years.

Cyera Research disclosed the issue on September 1, warning that the bug affects a core component used for backups, streaming replication, change data capture, failover, and database monitoring.

PostgreSQL is widely deployed across enterprise infrastructure and cloud platforms, making exposed replication credentials a potentially high-value target.

12-Year-Old PostgreSQL Flaw

PostGREShell resides in PostgreSQL’s logical replication mechanism. Organizations use logical replication to stream write-ahead log changes to standby instances, analytics platforms, migration tools, and change-data-capture services such as Debezium.

To consume those changes, a client creates a logical replication slot and supplies the name of an output plugin. The plugin is compiled native code such as a .so, .dll, or .dylib library that PostgreSQL loads into its server process to format replication data.

PostgreSQL ordinarily restricts non-superusers from loading arbitrary external libraries through its SQL LOAD command. A security check, check_restricted_library_name(), limits library loading to approved administrative directories and blocks dangerous paths.

Initiate streaming replication (Source: cyera)
Initiate streaming replication (Source: cyera)

However, Cyera said the logical replication path did not enforce the same validation. A user with the REPLICATION role could allegedly provide a plugin name containing absolute paths, traversal sequences such as ../, or Windows UNC paths.

PostgreSQL would then pass that value to operating-system library-loading functions, including dlopen() on Linux and macOS or LoadLibrary() on Windows. When the malicious library loads, its initialization code executes inside the PostgreSQL server process.

The impact differs by operating system and configuration. On Windows, an attacker may be able to host a malicious DLL on an SMB share and provide a UNC path to the database server.

If outbound SMB connectivity is enabled, PostgreSQL could remotely retrieve and load the DLL without the attacker first writing a file to the target system.

On Linux and macOS, exploitation may require an attacker-controlled library already stored locally. Systems that use NFS automounting could also be exposed to remote library delivery via network-mounted paths.

Successful execution would run under the operating system permissions of the PostgreSQL service account. From there, an attacker could manipulate PostgreSQL’s internal memory and catalog structures to obtain superuser-level database access, bypassing normal SQL permission checks.

PostgreSQL account with the REPLICATION  (Source: cyera)
PostgreSQL account with the REPLICATION  (Source: cyera)

A PostgreSQL superuser can read sensitive application data, access credentials stored in databases, write files, and, in some configurations, run operating-system commands via database features.

Cyera warned that a malicious plugin could also alter pg_hba.conf, register itself in shared_preload_libraries, or restore unauthorized privileges after an administrator attempts remediation.

Vladimir Tokarev said a VirusTotal hunt identified 114 suspicious PostgreSQL plugins, including cryptocurrency miners, trojans, and reverse shells.

The presence of such samples does not by itself confirm exploitation of CVE-2026-6471, but it illustrates the broader risk of untrusted database extensions.

Mitigation

Administrators should immediately apply PostgreSQL’s security updates addressing CVE-2026-6471 and review every account assigned the REPLICATION attribute. Replication access should be limited to trusted hosts through restrictive pg_hba.conf rules.

Organizations should also block unnecessary outbound SMB traffic on port 445 and NFS traffic on port 2049 from database servers, disable unused automount services, and monitor for unexpected CREATE_REPLICATION_SLOT activity. Plugin names containing slashes, backslashes, or traversal strings should be treated as high-priority indicators of possible exploitation.

Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection



Source link