# PostgreSQL's 12-Year Logical Decoding Flaw Hands Replication Accounts OS-Level Code Execution
## The Threat
A vulnerability hiding inside PostgreSQL's logical decoding subsystem for twelve years has finally been patched — and the timeline alone should give database administrators pause. Logical decoding, introduced in PostgreSQL 9.4 back in 2014 to enable change-data-capture and replication streaming, carried a flaw that allows any account holding the REPLICATION attribute to execute arbitrary code as the operating-system user running the database server. That typically means postgres, a service account with full control over every data file on disk.
The attack surface is narrower than a full anonymous exploit but far broader than it should be. The REPLICATION attribute is not a superuser privilege — it's handed out routinely to service accounts, ETL pipelines, and CDC tooling like Debezium, pgoutput consumers, and streaming replication standbys. In many organizations, these accounts are treated as low-risk because they aren't supposed to touch data directly. This vulnerability makes that assumption dangerous.
What makes CVE-2026-6471 particularly uncomfortable is the gap between discovery and exposure: every production PostgreSQL deployment running version 9.4 or later has been sitting on this flaw, and any environment that granted the REPLICATION role to an application account — a common, documented practice — was potentially one compromised service account away from OS-level access to the database host.
## Severity and Impact
| Field | Detail |
|---|---|
| CVE | CVE-2026-6471 |
| CVSS Score | 7.2 (High) |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H |
| CWE | CWE-284 — Improper Access Control |
| Attack Complexity | Low |
| Authentication Required | Yes — account with REPLICATION attribute |
| User Interaction | None |
| Scope | OS-level code execution as the database service user |
| Introduced | PostgreSQL 9.4 (2014) |
## Affected Products
All PostgreSQL major versions from 9.4 onward are affected. Patches are available for currently supported branches only:
Patched versions (upgrade to these):
Vulnerable and no longer supported (no patch available):
Organizations running EOL branches must treat this as a migration forcing function — no backport patches will be released for unsupported versions.
## Mitigations
Immediate actions:
REPLICATION attribute grants. Run the following against your databases to enumerate every account that holds this privilege:```sql
SELECT rolname, rolreplication FROM pg_roles WHERE rolreplication = true;
```
Remove the attribute from any account that does not have a documented operational requirement for it.
pg_hba.conf host-based authentication rules and, where possible, firewall policy. Blocking arbitrary source IPs from reaching port 5432 limits the blast radius even before patching.REPLICATION role grants to the absolute minimum and treat those hosts as high-risk until migration is complete.Workaround (if patching is delayed): Revoke the REPLICATION attribute from all non-essential accounts. This breaks any CDC pipeline relying on logical decoding slots but eliminates the attack vector until a maintenance window is available for patching.
## References
---
## HackWire Analysis
Twelve years. That number deserves to sit for a moment before we talk patches and CVSS scores.
Logical decoding shipped in PostgreSQL 9.4 in December 2014 as a foundation for change-data-capture — the technology that now underpins a massive slice of the modern data stack. Debezium alone claims millions of deployments. Every Kafka pipeline streaming database changes, every event-sourcing architecture, every real-time analytics platform pulling row-level changes from PostgreSQL has almost certainly been handing out REPLICATION role grants as part of its setup guide. Those guides didn't come with a footnote saying "by the way, this account can now run shell commands on your database host."
The deeper issue here isn't the vulnerability itself — it's what it reveals about how the security community treats database-internal privilege boundaries. The REPLICATION attribute occupies an awkward middle ground: more powerful than a read-only role, less scrutinized than a superuser. That ambiguity creates exactly the kind of oversight gap that persists for a decade unnoticed.
For defenders, the audit step matters more than the patch right now. Most organizations will patch within weeks. Far fewer will go back and audit every REPLICATION grant accumulated over years of infrastructure buildout, onboarding runbooks, and containerized deployments where the default connection string just worked. That accumulated attack surface doesn't disappear with a version bump.
Industries running regulated workloads — healthcare, finance, and any sector subject to data breach notification laws — should treat any REPLICATION-credentialed account as a potential lateral movement vector and review their threat models accordingly. OS-level code execution on a database host is a complete compromise by any reasonable definition.
— HackWire Editorial
---
## Related Coverage