Postgres CVE-2026-6471: your CDC user can load code

The account your change-data-capture pipeline logs in with is not a read-only account. Postgres CVE-2026-6471 means any non-superuser holding the REPLICATION attribute can pick an arbitrary library as a logical decoding output plugin, and the server will dlopen it — running whatever code that library contains as the operating system user Postgres runs as. The PostgreSQL Global Development Group fixed it on August 13 in 18.6, 17.11, 16.15, 15.19 and 14.24. The bug has been there since logical decoding shipped in 9.4, twelve years ago.

What actually happened

The project's own wording is blunt: "Missing authorization in PostgreSQL logical decoding allows a non-superuser holding REPLICATION privilege to dlopen any file visible to the operating system account running the server, via the choice of logical decoding plugin, which in turn runs arbitrary code as that account." It carries a CVSS of 7.2 with the vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H.

The mechanics are dull, which is why it survived so long. CREATE_REPLICATION_SLOT takes a plugin name, and that name was never constrained the way LOAD is constrained. The Hacker News reports that exploitation needs wal_level = logical — exactly the configuration you set when you turned on Debezium, a Fivetran connector, or a logical replica.

The fix is a new server parameter. From the Postgres 18 configuration docs, output_plugin_libraries "lists the libraries installed in dynamic_library_path that are also trusted for use as logical output plugins by replication clients. Any logical decoding or replication requests for other libraries will be refused." It defaults to 'pgoutput, test_decoding' — the two plugins that ship with Postgres — and the docs are explicit that all users are subject to this restriction, superusers included.

That default is the part that will bite you. It is an allowlist, and it does not know about wal2json, decoderbufs, or anything else you installed.

Why a replication privilege matters for your business

PR:H in that vector reads as "needs high privileges," and a scanner will deprioritize it accordingly. That is the wrong read for most small stacks, because REPLICATION is a privilege teams hand out casually. Backup tooling gets it. Standby servers get it. CDC pipelines get it. Monitoring agents get it. Every one of those is a service account with a credential sitting in an environment variable, a CI secret, or a vendor's dashboard — and any of those leaking now means code execution on your database host, not just a copy of your rows.

Do these four things, in order.

Inventory what actually decodes. Run SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; before you upgrade. If anything comes back that is not pgoutput or test_decoding, it will stop working after the patch until you add it to output_plugin_libraries and reload.

Upgrade to the August 13 minor release for your branch. That release closed 28 security issues and over 110 bugs, so you are not making the trip for one CVE.

Audit who holds the attribute with SELECT rolname FROM pg_roles WHERE rolreplication; and take it away from anything that does not stream WAL for a living. A monitoring agent almost never needs it.

Scope replication at the network layer. Tighten the replication lines in pg_hba.conf to the hosts that actually replicate. If a managed provider runs your Postgres, get their patch date in writing rather than assuming it.

Sources: PostgreSQL CVE-2026-6471 advisory, PostgreSQL 18 replication configuration docs, PostgreSQL 18.6 release announcement, The Hacker News.