The Postgres security update can switch your CDC off

Cover image

Cover illustration, no legible text. A continuous flow of strokes reaches a narrow opening and stops in front of it. Beside the opening, a small list with two filled marks and empty space below, suggesting a roster of allowed names with slots left to fill.

It is Tuesday, and the sales dashboard is still showing Friday.

The pipeline is not showing a red error, and the source database is up. Over the weekend there was a maintenance window and the server moved up a version. The problem is that reading the transaction log stopped being accepted, and nobody connected the two.

In this article we explain what the August security fix changed in PostgreSQL, why it takes down part of the replications out there, and what to ask before the next window.

What the August 13 fix changed

Logical decoding is the mechanism that lets an external tool read database changes straight from the transaction log. It has been there since version 9.4, back in 2014, and it underpins almost every CDC (change data capture) setup on PostgreSQL.

The choice of output plugin was never checked. An account holding the replication privilege could point at any library visible to the operating system user running the server, and the database would load it. Loading an arbitrary library means running arbitrary code as that user.

That became CVE-2026-6471, scored 7.2 on the CVSS 3.0 scale. Versions before 18.6, 17.11, 16.15, 15.19 and 14.24 are affected, and the fix shipped on August 13, 2026, in the same batch that closed 28 vulnerabilities.

The door stayed open for twelve years.

The output_plugin_libraries parameter and its default

The fix does not turn logical decoding off. It now requires the plugin library to sit on a list declared on the server, through the output_plugin_libraries parameter.

The default only carries what ships in the box. The list starts with pgoutput and test_decoding, the two plugins that come with PostgreSQL. Anything else is refused until somebody adds the name to the parameter and the server configuration is applied.

The documentation is explicit about the reach: the restriction applies to all users, and any logical decoding request for a library outside the list is refused. This is not a privilege you get around by switching accounts.

This is where the bill changes hands. A tool using pgoutput keeps reading as before. A tool that depends on wal2json, on decoderbufs or on any separately installed plugin finds the door shut right after the update.

How to know whether this hits you

You do not have to wait for the maintenance window to find out. Three queries answer it, and all of them run with read permission on the source database.

-- 1. which version the server is on
SELECT version();

-- 2. which replication slots exist and which plugin each one uses
SELECT slot_name, plugin, slot_type, active
  FROM pg_replication_slots;

-- 3. if the server was already updated, the parameter exists and shows the list
SHOW output_plugin_libraries;

The plugin column is the one that answers. If it shows pgoutput on every slot, the update changes nothing for you. If any other name shows up, that name has to reach the server list before the update, not after.

The third query has a useful side effect. As long as it returns an error saying the parameter does not exist, the server has not been patched yet. In that case you are on the wrong side of the vulnerability, not on the wrong side of the list.

Run the three of them on every source you replicate, not only on the one you remember. A team of one or two people usually has more slots open than it can name from memory, and the forgotten slot is the one that breaks.

Ask before Sunday comes.

What to ask whoever administers the database

The fix is short, and it is not yours to apply unless the database is yours. What changes is adding the plugin to the list and applying the server configuration.

• Before the window. Hand whoever runs the server the list of plugins showing up in pg_replication_slots. It is one configuration line, not a project.
• If the source is managed by a provider. The list usually becomes a parameter in the instance configuration group, and the change may require a restart. That belongs inside the window, not after it.
• If the update already happened. Reading resumes as soon as the plugin name reaches the list. Changes from the gap stay in the log while the slot exists and there is disk left to hold them.

That third item has a deadline. A stalled slot holds log, held log fills disk, and a full disk takes the whole production database down. Fixing the list is urgent for that reason, not for the late report.

The plugin project usually says what to do. The wal2json README, for one, documents the change citing the CVE and hands over the ready-made line, with the plugin name added to the two that ship by default. It pays to open the documentation of the plugin you use before writing the request.

What this fix costs you

The fix closes a real flaw, and it still charges. It pays to know what it charges before treating the matter as a line on the DBA list.

Switching plugins is not switching a setting. The output plugin defines the format in which the change leaves the database, and the tool on the other side has to understand that format. Moving to pgoutput just to escape the list means changing the reading mechanism, not one line in a file.

The decision may not be yours. On a managed instance, the parameter only changes if the provider exposes it in the configuration group. When it does not, all you can do is file a ticket and wait, with the pipeline stopped meanwhile.

Going back is not a way out either. Holding the old version to keep replication running keeps the vulnerability open, and it is exploited through exactly the credential your pipeline carries. Whoever put it off on 14 still has the November 12, 2026 end of support shortening the window.

The cost is coordination, not code.

What the release announcement leaves out

The August 13 announcement highlights three situations that need an extra step after updating: parallel GIN index builds, btree_gist and ltree. The change in how decoding plugins are loaded is not on that list.

That is not an omission, it is scope. The announcement list covers things that corrupt data or indexes. A refused slot corrupts nothing: it simply stops delivering, and the person who finds out is whoever opens the report on Monday.

It is also worth sizing the vulnerability without inflating it. The official vector requires high privilege: whoever exploits it already needs an account carrying the replication attribute. This is not an open door on the internet, it is an escalation from a credential that backup tools and CDC pipelines routinely hold.

And that is exactly what makes it worth attention. The account your pipeline uses every day is the account that serves the escalation, and it tends to be stored in more places than the superuser password.

Two urgencies, one window.

Where Januss comes in

Which output plugin a connection asks for is a question for each tool vendor, and Januss is no exception: that answer comes from whoever operates the product, not from this article. What we can show here is what happens on the day the database refuses the read.

Januss checks the prerequisites before saving the source. It verifies things like wal_level, binlog_format and CDC being enabled on SQL Server, and shows on screen the command that fixes whatever is missing, including the different path on Amazon RDS.

The warning does not wait for you to look. A failure sends an email with the error and a direct link to the run, and after three failures in a row the pipeline switches itself off instead of burning through your allowance. When the database log rotates before the read, the reload is automatic, because losing your position in the log is a data problem, not a scheduling one.

Want to see that behaviour against your own source? The 14-day trial asks for no card, and the prerequisite check runs before a single row is read. Create your Januss workspace.

Sources

The description of the flaw, the affected versions and the fix date are on the project official page; the ready-made configuration line is in the documentation of the most widely used plugin:

• PostgreSQL — CVE-2026-6471: logical decoding can dlopen arbitrary file
• PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released!
• wal2json — output plugin for PostgreSQL logical decoding