Who Holds REPLICATION on Your Postgres, and Why CVE-2026-6471 Makes It Matter

What the Advisory Actually Says

The PostgreSQL project's own wording is short, and it is worth reading before any of the coverage.

Missing authorization in logical decoding lets a non-superuser holding the REPLICATION privilege dlopen any file visible to the operating system account running the server, through the choice of logical decoding plugin, and that runs arbitrary code as that account.

The score is 7.2, and the vector is the interesting part. AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. Everything after the impact is as bad as it gets, confidentiality, integrity and availability all high, because code running as the postgres user owns the database completely.

But PR:H means privileges required, high. This is not something a stranger does to you. It is something done by an account you already created, already granted REPLICATION to, and probably already forgot about.

Three Things the Coverage Gets Wrong

It is not a zero-day. The fix shipped on 13 August 2026 in 18.6, 17.11, 16.15, 15.19 and 14.24. That is three and a half weeks of patch availability before the articles appeared, which is the opposite of the Magento situation from last week where stores were being taken while Adobe had nothing to install.

The twelve years describe the code, not the exposure. Logical decoding arrived in 9.4 in 2014 and the missing check has been there since. That is a fair thing to say about the commit history and a misleading thing to imply about your risk, because the precondition has been the same for those twelve years too.

And at least one write-up lists a reachable SMB port 445 as a prerequisite. It is not one. That is a Windows-specific way to make the malicious library visible to the server through a UNC path. The advisory says any file visible to the operating system account, so on a Linux host the attacker needs the file on that host, which is a materially higher bar than an open port somewhere on the network.

Why High Privileges Are Not a Reason to Relax

Here is the part that should make you go and look rather than close the tab.

REPLICATION gets handed out casually. It is the privilege you grant when you set up a read replica, when you attach a change-data-capture pipeline, when an analytics vendor asks for a logical slot, when a migration tool wants to stream rather than dump, or when someone was debugging a replica at eleven at night and granted it to the application user to make the error go away.

Every one of those is a legitimate reason to grant it. None of them is a reason to still hold it a year later.

So the flaw converts a privilege that many teams treat as routine and low-consequence into arbitrary code execution as the database account. That reframing is the actual news. Before this, a leaked replication credential meant somebody could read your write-ahead log, which is bad. Now it means somebody can run commands on the database host.

Find Out Who Has It

This is two minutes and it needs nothing installed.

SELECT rolname, rolsuper, rolreplication, rolcanlogin
FROM pg_roles
WHERE rolreplication OR rolsuper
ORDER BY rolname;

Read the result with one question in mind. For every row that can log in and has replication, can you say what it is for, and would you notice if its password appeared somewhere it should not?

Then the server itself:

SHOW server_version;
SHOW wal_level;

The version tells you whether you are patched. The second one is worth knowing because creating a logical replication slot needs wal_level = logical, and the default is replica. A server that never had logical decoding turned on is not reachable through this particular door.

Treat that as a mitigating factor rather than an all-clear. The project's advisory does not list it as a precondition, and plenty of stacks quietly set it, since change-data-capture tools, some managed replication offerings and several migration tools all want it.

Last, look at who is allowed to connect as a replication client at all:

grep -E '^(host|hostssl).*replication' "$(psql -tAc 'SHOW hba_file')"

A replication line answering 0.0.0.0/0 is a bigger finding than the CVE.

Patch, and Know What Patching Does Not Do

Upgrade to 18.6, 17.11, 16.15, 15.19 or 14.24, whichever line you are on. These are minor releases, so the upgrade is a package update and a restart rather than a dump and reload, and the project has kept that promise consistently.

What patching does not do is tell you whether a replication credential is already somewhere it should not be. The fix closes the route from that account to code execution. It does nothing about the account itself, and if one leaked six months ago the holder still has everything replication was always able to read.

If you find a replication role you cannot account for, rotating its password is the cheap half of the job. The other half is working out where it was used, because something breaks when you rotate it and finding out what breaks is how you learn what had it.

What a Replication Account Should Look Like

Four things, none of them new advice, all of them worth checking today because now they carry a different consequence.

Replication belongs on its own role, not bolted onto the account your application connects with. If your app user has REPLICATION, this CVE turns an SQL injection in your application into code execution on the database host.

That role should not be a superuser. It does not need to be, and the CVE is specifically about the non-superuser case, which means somebody already thought the boundary was worth something.

Its pg_hba.conf entry should name the replica's address rather than a range, and should require TLS.

And it should be in whatever inventory you keep of credentials that matter, next to the cloud keys, rather than living only in the memory of whoever set up the replica.

If You Cannot Patch This Week

Some databases do not get restarted on a Monday afternoon, and a managed provider may not have rolled the minor release out to you yet.

In that case the useful interim move is not a firewall rule. It is to revoke REPLICATION from every role that does not currently need it, which is a single statement per role and is worth doing whether or not you ever patch:

ALTER ROLE some_role NOREPLICATION;

That removes the precondition rather than the vulnerability, and unlike most interim measures it is one you should want to keep afterwards.

If you are on a managed service, check the provider's status page rather than assuming. The patch date is 13 August and the major providers move at different speeds, so the honest answer for a managed instance is usually written down somewhere rather than guessable.

Sources: PostgreSQL, CVE-2026-6471, PostgreSQL security page, Cyber Security News