PostgreSQL has released security updates to address a vulnerability that could allow an account with the REPLICATION attribute to execute arbitrary code as the operating system user running the database server. The flaw, tracked as CVE 2026 6471 with a CVSS score of 7.2, has existed since logical decoding was introduced in PostgreSQL 9.4 in 2014. According to PostgreSQL, the issue affects versions earlier than PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24. Exploitation requires an account that possesses the REPLICATION attribute and a database server configured with wal_level set to logical. Such permissions are commonly assigned to backup tools, standby servers, change data capture pipelines, and monitoring systems, making the issue relevant for a wide range of enterprise database deployments.
To address the issue, PostgreSQL introduced a new server configuration parameter called output_plugin_libraries, which specifies the logical decoding output plugins that are permitted to load. By default, the parameter allows only pgoutput and test_decoding. Organizations using additional plugins such as wal2json or decoderbufs will need to explicitly add those libraries to the configuration before logical decoding can continue functioning after the update. PostgreSQL explained that the previous implementation allowed replication users to select any loadable library for logical decoding, creating the possibility for misuse. The project credited Vladimir Tokarev and Yu Kunpeng with reporting the issue. Tokarev later published technical details through Cyera Research, referring to the vulnerability as PostGREShell. According to the research, the plugin name supplied through a CREATE_REPLICATION_SLOT command is passed directly to the library loading function, allowing specially crafted paths to reach the loader. Existing protections that restrict plugin paths for non superusers were not applied during replication, allowing attackers to exploit directory traversal and other path manipulation techniques under specific conditions.
Cyera’s analysis showed that the exploitation method varies across operating systems. On Windows, attackers could potentially retrieve malicious libraries through Server Message Block network paths without writing files directly to the target system. On Linux and macOS, similar behavior would require Network File System automounting to be enabled, while other environments would require an existing method for placing a malicious library onto the server. Once loaded, the code executes within the PostgreSQL backend process using the postgres operating system account. During testing, Cyera demonstrated that a malicious plugin could directly modify the database role catalog to elevate a replication account to PostgreSQL superuser privileges while also creating persistence mechanisms that survive server restarts. PostgreSQL developers decided against applying the existing LOAD restrictions directly to the replication path because doing so would have disrupted compatibility with many existing third party output plugins. Instead, they implemented the new whitelist based approach to improve security while maintaining operational flexibility for administrators.
Administrators are advised to identify all logical decoding plugins currently in use before upgrading, install one of the fixed PostgreSQL releases, configure any required non default plugins within the new output_plugin_libraries parameter, and reload the server configuration without requiring a restart. PostgreSQL also recommends configuring the parameter before performing pg_upgrade checks when migrating from version 17 or later. Updated packages are already available through Amazon RDS, Debian, SUSE, Ubuntu, and other supported distributions. PostgreSQL noted that version 14 will reach end of support on November 12, 2026. As of September 4, a separate issue affecting pg_createsubscriber compatibility with the new parameter remained under review. CVE 2026 6471 had not been added to CISA’s Known Exploited Vulnerabilities catalog, and no public proof of concept code had been identified. Until updates are deployed, Cyera recommends limiting REPLICATION privileges only to required accounts, restricting replication access through pg_hba.conf, blocking outbound SMB and NFS traffic from database servers where appropriate, and disabling autofs on systems where it is not needed to reduce potential exposure.
Follow the SPIN IDG WhatsApp Channel for updates across the Smart Pakistan Insights Network covering all of Pakistan’s technology ecosystem.
