For 12 Years, PostgreSQL’s Replication Privilege Could Escape the Database
PostGREShell, tracked as CVE-2026-6471, allowed a PostgreSQL account holding the powerful REPLICATION privilege to make the database server load an arbitrary library. The result was code execution as the operating-system account running PostgreSQL.
That is not the same as an unauthenticated internet attack. Ordinary PostgreSQL users do not receive REPLICATION by default, and the vulnerability does not let any basic database login take over a host. An attacker first needs credentials for a role that administrators have explicitly trusted to initiate replication.
The boundary failure is still serious. Replication accounts are often treated as specialised operational plumbing for backups, standby servers, migration tools and change-data-capture systems. PostgreSQL intended that privilege to move database changes. It was never supposed to grant a path into executable code on the server beneath the database.
PostGREShell crossed from database authority into the operating system
PostgreSQL logical decoding converts changes from the write-ahead log into a format that another service can consume. A client creates a logical replication slot and selects an output plugin, such as the built-in pgoutput plugin or a third-party alternative.
Those plugins are native libraries. Loading one places compiled code inside the PostgreSQL server process. PostgreSQL already restricts library names in other paths, but the official PostgreSQL advisory says logical decoding was missing the required authorisation check.
A non-superuser with REPLICATION could therefore choose an arbitrary file visible to the operating-system account that runs PostgreSQL. If the database process could reach and load the file, its code ran with that operating-system account’s privileges.
The official impact stops there: arbitrary code execution as the PostgreSQL operating-system user. Cyera Research, which discovered the flaw and named it PostGREShell, then demonstrated a further attack chain. Its researchers say malicious plugin code can manipulate PostgreSQL internals, grant database-superuser privileges and establish persistence that survives a restart.
The prerequisite changes the risk, but not the trust failure
PostgreSQL scores CVE-2026-6471 at 7.2. The vector reflects network reachability, low attack complexity, no user interaction and a high-privilege prerequisite. That final condition is crucial when deciding which environments need the fastest response.
A deployment with no non-superuser replication roles does not present the same path as a production estate where backup agents, standby systems, migration services and analytics pipelines all hold long-lived replication credentials. The real inventory question is therefore not simply whether PostgreSQL is installed. It is where REPLICATION exists, who can use it and which systems can reach those accounts.
This is also why credential theft matters. A replication account may have fewer SQL permissions than an application administrator, yet PostGREShell turned that narrower database role into a route to the host process. Least privilege failed because the permission model did not contain the native plugin loader behind it.
BlackTree has previously examined why privileged access is a resilience issue. PostGREShell shows that the inventory must include specialised service accounts, not only human administrators.
Windows offered the cleanest remote path
Cyera’s technical analysis shows that the route to a malicious library depends on the operating system and network configuration. On Windows, a crafted plugin path could reference a library on an attacker-controlled SMB share. If the PostgreSQL service could make the outbound connection, Windows could retrieve and load that DLL without the attacker first placing it on the local disk.
Cyera also describes a network-assisted route on Linux or macOS systems using NFS automounting. In more typical Linux containers and servers without that behaviour, the attacker would need some other way to place a malicious shared library where the PostgreSQL operating-system account could read it.
These conditions should stay attached to the story. The vulnerability is not equally remote on every platform, and it does not erase the need for a valid REPLICATION credential. The important point is that once those prerequisites are met, a database protocol designed for data movement can become a native-code loader.
PostgreSQL fixed supported releases in August
PostgreSQL published fixes on 13 August 2026. The project identifies the following supported branches and fixed versions:
| PostgreSQL branch | Affected versions | Fixed version |
|---|---|---|
| 18 | Before 18.6 | 18.6 |
| 17 | Before 17.11 | 17.11 |
| 16 | Before 16.15 | 16.15 |
| 15 | Before 15.19 | 15.19 |
| 14 | Before 14.24 | 14.24 |
Cyera reports that the underlying vulnerable path dates back to PostgreSQL 9.4, released in 2014. Those older branches are outside the official supported-version table. Organisations still running them should migrate to a supported, fixed release rather than interpret the absence of an old branch from the table as evidence that it is safe.
BlackTree previously covered a different PostgreSQL code-execution flaw in The Database Login Became a Shell. The comparison matters: both bugs crossed from SQL-level access into the server operating system, but they use different components, prerequisites and fixed versions. Patching one does not substitute for patching the other.
No malicious exploitation of PostGREShell has been confirmed
Cyera says a VirusTotal search found 114 malicious PostgreSQL plugins, including miners, reverse shells and trojans. That demonstrates that malicious native modules already exist. It does not establish that attackers used CVE-2026-6471 to load any of them.
No malicious exploitation of this vulnerability has been confirmed. It is not in CISA’s Known Exploited Vulnerabilities catalogue at the time of writing, and BlackTree found no verified incident connecting the PostGREShell path to an intrusion.
Technical details are public, however, and Cyera’s research explains the vulnerable path and platform-specific delivery options. Defenders should distinguish that availability from evidence of real-world abuse while recognising that disclosure reduces the work required to reproduce the technique.
What PostgreSQL defenders should do now
- Upgrade every supported PostgreSQL branch to at least 18.6, 17.11, 16.15, 15.19 or 14.24, as applicable.
- Identify older unsupported PostgreSQL releases and move them to a supported fixed branch.
- Inventory every role holding
REPLICATION. Remove the attribute where it is no longer required. - Review
pg_hba.confand allow replication connections only from the specific trusted systems that need them. - Rotate replication credentials that are shared, long-lived, weakly stored or accessible to more services than necessary.
- Restrict outbound SMB on TCP port 445 and NFS on TCP port 2049 from database servers unless an approved operational dependency requires them.
- Review logical replication slots and investigate unexpected creation events, unusual plugin names, path separators or replication traffic from unfamiliar hosts.
- After patching, verify the version running on each instance. A package downloaded to a repository is not proof that the database process has restarted on the fixed build.
Managed database customers should verify the provider’s running version and maintenance status rather than assume the service name guarantees a fixed build. They should also establish whether their service exposes the REPLICATION privilege and which parts of role management, credentials, network access and replication relationships remain under customer control.
The hidden risk was authority that looked narrower than it was
PostGREShell is not a story about every PostgreSQL user becoming root. It is a story about a specialised privilege that crossed a boundary its operators reasonably expected to hold.
A replication role was allowed to select a component that PostgreSQL loaded as native code. Once the database process accepted that choice, SQL permissions could no longer contain what happened next. Cyera’s persistence demonstration makes the consequence vivid, but the official vulnerability is already serious before that later chain begins.
The practical lesson is to inventory authority by what a credential can cause, not only by the label attached to it. “Replication only” sounded narrow for 12 years. The loader behind it made that assumption false.
PostGREShell questions
Can an unauthenticated attacker exploit PostGREShell?
No. The PostgreSQL advisory requires a non-superuser account holding the REPLICATION privilege. That privilege is powerful and is not granted to ordinary users by default.
What does the vulnerability let an attacker do?
The official impact is arbitrary code execution as the operating-system account running PostgreSQL. Cyera separately demonstrated how malicious code inside the server process could obtain PostgreSQL superuser authority and establish persistence.
Has PostGREShell been exploited in attacks?
No malicious exploitation of CVE-2026-6471 has been confirmed. Malicious PostgreSQL plugins found by Cyera are not evidence that attackers loaded them through this vulnerability.
Which PostgreSQL versions fix it?
PostgreSQL lists 18.6, 17.11, 16.15, 15.19 and 14.24 as the fixed releases for the supported branches.
Sources and further reading
- PostgreSQL security advisory for the logical-decoding vulnerability, fix published 13 August 2026. The page provides no publication time.
- Cyera Research: PostGREShell, published 1 September 2026. The page provides no publication time.
