PostgreSQL has released security updates that fix the CVE-2026-6471 vulnerability (CVSS 7.2) in the logical decoding mechanism. The flaw allows a database account with the REPLICATION attribute to load an arbitrary library and execute code as the system user under which the server runs. All supported branches are affected — PostgreSQL 14, 15, 16, 17, and 18 up to versions 14.24, 15.19, 16.15, 17.11, and 18.6 respectively. The fix, released on 13 August 2026, introduces a new configuration parameter that may break third‑party plugins after the update unless the administrator performs additional configuration.
Nature of the vulnerability and attack vector
According to the official PostgreSQL advisory, the issue is classified as a missing authorization check in the server core during logical decoding. A user with the REPLICATION privilege could specify an arbitrary loadable library as an output plugin — bypassing the checks that are applied to regular library loading operations via the LOAD command.
The official CVSS vector is AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H — a network attack vector with low exploitation complexity but high privilege requirements. The impact is rated as high across all three dimensions: confidentiality, integrity, and availability. Two conditions are required for exploitation: an account with the REPLICATION attribute and a server configuration with wal_level = logical.
The REPLICATION attribute is often assigned to service accounts: backup tools, replica servers, change data capture (CDC) pipelines, and monitoring systems. This broadens the potential attack surface despite the formally high level of required privileges.
Fix mechanism: the output_plugin_libraries parameter
As stated in the PostgreSQL 18.6 release notes, the fix introduces the server parameter output_plugin_libraries — a whitelist of libraries that are allowed to be loaded as logical decoding output plugins. The default value is 'pgoutput, test_decoding'.
This means that after the update any third‑party plugin — including widely used ones such as wal2json and decoderbufs — will be rejected by the server until the administrator explicitly adds it to the list and reloads the configuration. When a plugin is rejected, the server log records a message: ERROR: library "..." may not be used as an output plugin with a reference to the output_plugin_libraries parameter.
Jacob Champion, the author of the fix, explained in the commit that the standard LOAD restrictions were intentionally not applied to the replication path: retroactively introducing them would have required all third‑party plugins to be installed in the $libdir/plugins directory, which would have broken existing installations.
Who is at risk
The vulnerability affects any PostgreSQL 14–18 installation where two conditions are met simultaneously: there is an account with the REPLICATION attribute and the server runs with wal_level = logical. This is a typical configuration for:
- Logical replication systems between PostgreSQL clusters
- CDC pipelines (Debezium, Kafka Connect, and similar tools)
- Backup tools that use logical decoding
- Monitoring platforms that use replication slots
Code loaded via exploitation of the vulnerability executes inside the server process as the postgres system user, potentially giving the attacker full control over the data and the ability to establish persistence on the system.
Practical recommendations
The recommended update procedure, according to the PostgreSQL documentation, is as follows:
- Inventory your plugins — before updating, run the query:
SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;This query shows plugins that have ever been used successfully. - Update to PostgreSQL 18.6, 17.11, 16.15, 15.19, or 14.24. Packages are available from major distributors: Amazon RDS (from 25 August), Ubuntu (22.04, 24.04, 26.04 LTS), Debian, and SUSE.
- Add third‑party plugins to
output_plugin_librariesand reload the configuration usingpg_ctl reloadorSELECT pg_reload_conf();— a full server restart is not required. - When migrating from PostgreSQL 17 or newer via pg_upgrade: set
output_plugin_librarieson the new cluster before runningpg_upgrade --check, otherwise the check will fail if slots on the old cluster use plugins that are not present in the list.
Temporary measures before updating
- Revoke the REPLICATION attribute from accounts that do not require it
- Restrict replication entries in
pg_hba.confto known IP addresses - Block outgoing traffic from database servers on ports 445 (SMB) and 2049 (NFS)
Exploit status and open questions
At the time of publication, there is no confirmation of active exploitation of CVE-2026-6471. No public proof‑of‑concept exploit code has been found in open repositories. The vulnerability was discovered by researchers Vladimir Tokarev and Yu Kunpeng, as reported in the official release announcement.
It should be taken into account that PostgreSQL 14 — the oldest affected branch — will stop receiving security updates on 12 November 2026. Organizations running this version should plan a migration to a newer branch.
Updating to the fixed PostgreSQL versions should be treated as a priority, especially on servers with wal_level = logical. It is critically important not to stop at installing the patch: you must review the list of output plugins in use, add them to output_plugin_libraries, and ensure that logical replication and CDC pipelines continue to operate after the update. Skipping this step will lead to logical decoding failures — an operational issue, but one that is predictable and easy to remediate.
