A Ten-Year-Old PostgreSQL Flaw Let a Backup Account Become a Backdoor
A security gap in widely used database software, hidden since 2014, could let a low-level account take over an entire server. Patches are out. Here is what you need to know.
Key points
- Researchers at Cyera identified a flaw, tracked as CVE-2026-6471, in PostgreSQL, one of the world's most widely used open-source databases, dating back to version 9.4 released in 2014.
- The flaw sits inside a feature called logical replication and lets an attacker with only a low-level "backup" account load and run their own malicious code on the database server.
- Patched versions, including PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24, were released on 13 August 2025.
- Cyera's researchers found 114 malicious PostgreSQL plugins already circulating in the wild, including software that mines cryptocurrency and tools that hand attackers remote control of a machine.
- Database administrators should patch immediately, audit which accounts hold the REPLICATION attribute, and block outbound connections to file-sharing services from database servers.
What is the problem, in plain terms?
PostgreSQL is free, open-source database software used by banks, hospitals, retailers, and governments to store enormous amounts of sensitive data. A flaw in one of its internal features meant a low-level account, the kind you might hand to a contractor running backups, could be weaponised to take over the whole server.
The feature in question is called logical replication. Replication is the process of copying database changes to another system, for backups, live mirrors, or monitoring tools. To format those changes, PostgreSQL loads small pieces of compiled code called output plugins. The flaw, named PostGREShell by Cyera Research and first reported by CSO Online, is simple: when loading those plugins, PostgreSQL never ran its own security check that is supposed to stop non-administrator accounts from pointing the software at dangerous code.
How could an attacker use this?
An attacker with a replication account, a type of account that is common operational plumbing and rarely scrutinised, could craft a plugin name that contained a file-path to malicious code. PostgreSQL would load that code without challenge, and the code would run inside the database server itself, outside the normal rules that govern who can read or write what.
On Windows, the exposure is wider still. An attacker could host the malicious file on a remote file-sharing server elsewhere on the network, using a protocol called SMB (the same technology behind shared drives in offices). PostgreSQL would fetch and run it with no file needing to touch the target machine first.
Once inside, the malicious code can promote the attacker's account to a database superuser, meaning full access to every database, every customer record, every stored password, and every application secret. Cyera demonstrated that the access could also survive a full database restart through changes to authentication configuration files.
Which versions are affected, and what is fixed?
| PostgreSQL version | Patched release | Release date |
|---|---|---|
| 18.x | 18.6 | 13 August 2025 |
| 17.x | 17.11 | 13 August 2025 |
| 16.x | 16.15 | 13 August 2025 |
| 15.x | 15.19 | 13 August 2025 |
| 14.x | 14.24 | 13 August 2025 |
Versions as old as 9.4, released in 2014, carry the flaw. Any version no longer in the official support cycle receives no patch and should be treated as permanently exposed until upgraded.
Cyera reported the flaw to the PostgreSQL Security Team in February 2025. The team reviewed the findings, assigned the CVE identifier, and issued fixes in August.
Should database users be worried?
Yes, with a practical focus rather than alarm. The flaw requires an attacker to already hold a replication account, so the immediate concern is whether any such account has been stolen, shared carelessly, or handed to a third party without close oversight.
If your organisation uses PostgreSQL, apply the patches listed above as soon as possible. Check which accounts carry the REPLICATION attribute, remove it from any that do not need it, and ask your network team to block unnecessary outbound SMB and NFS (a file-sharing protocol similar to SMB, common on Linux networks) connections from database servers.
For individuals, this flaw is one layer removed from everyday risk. Its real danger is to the services you use: if a company stores your data in an unpatched PostgreSQL database with a poorly managed replication account, your records could be exposed without any action on your part. The practical step is the same as always: watch for breach notifications from services you use, and change passwords if one arrives.
