CVE-2026-6471: 12-Year-Old PostgreSQL PostGREShell Flaw Enables Server Takeover
Overview
CVE-2026-6471, also known as PostGREShell, is a PostgreSQL logical-decoding authorization vulnerability that allows a non-superuser with the REPLICATION privilege to cause the server to load an arbitrary library accessible to the PostgreSQL operating-system account. This can result in arbitrary code execution with the privileges of the account running PostgreSQL.
The vulnerability requires a valid PostgreSQL account with REPLICATION privilege and cannot be exploited by an unauthenticated attacker. Cyera Research reports that the vulnerable behavior dates back to PostgreSQL 9.4 in 2014, leaving it present for approximately 12 years. PostgreSQL rates the vulnerability High severity with a CVSS score of 7.2.
PostgreSQL has fixed the vulnerability in versions 18.6, 17.11, 16.15, 15.19, and 14.24. Organizations running affected versions should upgrade to the corresponding patched release or later.
| Vulnerability Name | PostgreSQL logical decoding can dlopen arbitrary file |
|---|---|
| CVE ID | CVE-2026-6471 |
| Research Name | PostGREShell |
| Severity | High |
| CVSS Score | 7.2 |
| Component | PostgreSQL core server / logical decoding |
| Privilege Required | Valid PostgreSQL account with REPLICATION privilege |
| Supported Affected Versions | PostgreSQL 18 before 18.6, 17 before 17.11, 16 before 16.15, 15 before 15.19, and 14 before 14.24 |
| Historical Exposure | Cyera Research reports the vulnerable behavior has existed since PostgreSQL 9.4, released in 2014 |
| Fixed Versions | 18.6, 17.11, 16.15, 15.19, and 14.24 |
| Fix Published | August 13, 2026, according to PostgreSQL's official security advisory |
| Discovered By | Cyera Research Labs / Vladimir Tokarev |
| Description | Missing authorization in the logical-decoding plugin-loading path allows a non-superuser with REPLICATION privilege to select an arbitrary library visible to the PostgreSQL server's operating-system account, resulting in arbitrary code execution as that account. |
Exploit Maturity Assessment
CVE-2026-6471 - PostGREShell
PostGREShell has moved beyond a purely theoretical flaw. Cyera Research developed a working Windows proof of concept during coordinated disclosure and publicly documented the technical exploitation path. The researchers demonstrated that a REPLICATION-privileged account can direct PostgreSQL to load attacker-controlled native code, resulting in code execution as the database service account.
| Factor | Assessment |
|---|---|
| Exploit Status | Functional researcher-demonstrated exploitation |
| Exploit Availability | Technical PoC details are publicly documented by the original researcher; this blog does not reproduce exploit code |
| Source of Exploit | Cyera Research, the original vulnerability reporter |
| Exploit Reliability | Demonstrated on Windows by the researcher; cross-platform prerequisites differ |
| In-the-Wild Exploitation | Not confirmed by PostgreSQL or Cyera for CVE-2026-6471 itself |
Cyera identified 114 malicious PostgreSQL plugins in VirusTotal, including reverse shells, cryptocurrency miners, and trojans. This is evidence that malicious PostgreSQL-native modules exist in the wild, but it does not prove those samples were delivered by exploiting CVE-2026-6471.
Proof of Concept
CVE-2026-6471 - PostGREShell
Cyera reported the vulnerability to the PostgreSQL Security Team with exploitation details and a Windows proof of concept. Its public research explains the minimal logical-replication flow used to select a malicious output plugin and describes how Windows UNC paths can allow the server to load a DLL from an attacker-controlled SMB share when the required network conditions are present.
| Publicly Available | Researcher-published technical PoC details are available |
|---|---|
| Purpose | Demonstrate arbitrary native-library loading through logical decoding using a REPLICATION-privileged account |
| Prerequisites | Valid PostgreSQL REPLICATION credentials; logical decoding available; a library path reachable or visible to the PostgreSQL OS account |
| Windows-Specific Condition | Cyera's demonstrated standalone Windows path requires the database server to be able to reach an attacker-controlled SMB share over TCP/445 |
| Expected Outcome | Arbitrary code execution as the operating-system account running PostgreSQL |
Reproducibility
CVE-2026-6471 - PostGREShell
The flaw is technically reproducible from the original research, but exploitation conditions vary by platform. On Windows, Cyera demonstrated remote library loading through a UNC path when outbound SMB is available. On Linux and macOS, PostgreSQL ultimately uses the operating system's dynamic loader, so an attacker needs a library path visible to the PostgreSQL service account. Cyera notes that network-mounted or automounted filesystems such as NFS can create a remote path on some systems; otherwise, a separate file-placement mechanism would be required.
At minimum, exploitation requires a valid account with the REPLICATION attribute. Cyera's demonstrated logical-decoding path also assumes a configuration where logical replication can be used, including an appropriate wal_level setting.
Time-to-Exploit Analysis
CVE-2026-6471 - PostGREShell
| Metric | Assessment |
|---|---|
| Vulnerability Introduced | Cyera traces the vulnerable behavior to PostgreSQL 9.4 in 2014 |
| Reported to PostgreSQL | February 21, 2026 |
| Vendor Confirmation | February 27, 2026 |
| Fix Coordination Confirmed | March 16, 2026 |
| Official Fix Publication | August 13, 2026, per PostgreSQL's security advisory |
| Public Research Publication | September 1, 2026 |
| Time from Historical Introduction to Fix | Approximately 12 years |
| Time from Private Report to Official Fix | Approximately 173 days |
| Time from Disclosure to Active Exploitation | Not established; confirmed exploitation of CVE-2026-6471 in the wild has not been demonstrated by the sources reviewed |
| Risk Interpretation | High priority. Exploitation requires privileged database credentials, but successful exploitation crosses the database-to-operating-system boundary and can lead to server takeover. |
Active Exploitation & Threat Actors
CVE-2026-6471 - PostGREShell
Exploitation Observed in the Wild: No confirmed in-the-wild exploitation of CVE-2026-6471 was identified in the PostgreSQL advisory or Cyera's research.
Associated Threat Actors: No named threat actor, APT group, ransomware operator, or initial access broker has been authoritatively linked to exploitation of this CVE.
Campaign Details: No exploitation campaign has been confirmed.
Malicious Plugin Evidence: Cyera's VirusTotal hunt identified 114 malicious PostgreSQL plugins, including reverse shells, miners, and trojans. These samples demonstrate an existing ecosystem of malicious PostgreSQL native modules, but Cyera does not establish that they were deployed through CVE-2026-6471.
Attack Techniques Observed: The researcher demonstrated library loading, code execution as the PostgreSQL OS account, escalation to PostgreSQL superuser through in-process access, and persistence techniques. These are laboratory/research findings, not evidence of a confirmed threat campaign.
Vulnerability Timeline
CVE-2026-6471 - PostGREShell
| Event | Date |
|---|---|
| Vulnerable behavior introduced | 2014, beginning with PostgreSQL 9.4 according to Cyera Research |
| Reported to PostgreSQL Security Team | February 21, 2026 |
| PostgreSQL acknowledged vulnerability | February 27, 2026 |
| Fix planned for minor release | March 16, 2026 |
| Official PostgreSQL fixes published | August 13, 2026 |
| Public Cyera technical analysis | September 1, 2026 |
| Confirmed exploitation in wild | Not established |
Root Cause Analysis
CVE-2026-6471 - PostGREShell
CVE-2026-6471 is caused by a missing authorization check in PostgreSQL's logical-decoding output-plugin loading path. PostgreSQL supports native extensions and output plugins implemented as shared libraries such as .so, .dll, or .dylib files. Loading such a module executes native code inside the PostgreSQL server process.
PostgreSQL already contains a restriction mechanism for dangerous library loading in other paths. Cyera's analysis shows that the logical-replication path failed to apply the equivalent restricted-library-name validation before passing the user-selected plugin name to the dynamic loader. As a result, a non-superuser holding REPLICATION privilege can supply path-like plugin names that reach dlopen() on Linux/macOS or LoadLibrary() on Windows.
The security boundary failure is therefore not that PostgreSQL supports native plugins; that behavior is intentional. The vulnerability is that a role which is not a database superuser can choose an arbitrary library path through the logical-decoding protocol without the authorization restriction normally expected for native code loading.
Impact
CVE-2026-6471 - PostGREShell
Successful exploitation turns a PostgreSQL REPLICATION credential into native code execution under the operating-system identity running the database server. This crosses an important security boundary: a database account intended for replication-related operations can obtain code execution in the server process without being a PostgreSQL superuser.
Cyera further demonstrated that once arbitrary native code runs inside the PostgreSQL process, the attacker can interact with internal PostgreSQL functionality from a trusted execution context and escalate to database-superuser capabilities. The practical result can therefore be compromise of both the database security boundary and the underlying server account.
Post-Exploitation Details
CVE-2026-6471 - PostGREShell
Cyera's research demonstrates a multi-stage post-exploitation path. Initial exploitation provides code execution as the PostgreSQL operating-system account. From that in-process position, the researchers show how an attacker can obtain PostgreSQL superuser capabilities because the loaded code executes inside PostgreSQL's trusted process rather than through normal SQL permission checks.
The research also describes persistence possibilities involving PostgreSQL configuration and startup behavior, including modification of pg_hba.conf, use of shared_preload_libraries, and mechanisms that can restore privileged database access after restart. These are researcher-demonstrated possibilities, not behaviors confirmed in an in-the-wild CVE-2026-6471 campaign.
| Capability | Assessment |
|---|---|
| Code Execution | Confirmed technical impact as PostgreSQL OS account |
| Database Superuser Escalation | Demonstrated by Cyera Research after native code execution |
| Persistence | Researcher-described through PostgreSQL configuration/startup mechanisms |
| Lateral Movement | Not established for this CVE |
| Data Exfiltration | Possible after database/server compromise; not documented as observed exploitation |
| Command and Control | No CVE-specific campaign infrastructure identified |
MITRE ATT&CK Mapping
| CVE | Tactic | Technique | ID |
|---|---|---|---|
| CVE-2026-6471 | Initial Access / Credential Context | Valid Accounts - exploitation requires a valid PostgreSQL role with REPLICATION privilege | T1078 |
| CVE-2026-6471 | Execution | Shared Modules - exploitation causes PostgreSQL to load and execute a native shared library | T1129 |
Vulnerability Chaining Opportunities
CVE-2026-6471 - PostGREShell
The vulnerability does not inherently provide initial credentials: an attacker first needs a PostgreSQL role with REPLICATION privilege. This makes credential theft, exposed backup credentials, overly permissive replication accounts, or another authentication weakness plausible precursors in a broader attack chain.
On Windows, Cyera demonstrated that a reachable attacker-controlled SMB location can provide the malicious DLL without first writing it to the database server's local disk. On Linux or macOS, a network-mounted or automounted filesystem can provide an equivalent path in some environments. Where no remotely accessible library path exists, an attacker would need a separate method to place a malicious shared library somewhere visible to the PostgreSQL service account.
A high-level defensive chain is therefore:
Obtain REPLICATION credentials to reach logical decoding to select attacker-controlled library path to PostgreSQL loads native code to code executes as database OS account to escalate within PostgreSQL / establish persistence.
Detection and Monitoring
CVE-2026-6471 - PostGREShell
Detection should focus on both privilege exposure and unusual logical-replication activity. Inventory all PostgreSQL roles that hold the REPLICATION attribute and verify that each one still requires it. Review pg_hba.conf to ensure replication connections are restricted to expected hosts and networks.
Cyera recommends monitoring for unexpected CREATE_REPLICATION_SLOT activity, replication connections from unfamiliar source addresses, suspicious output-plugin names, and plugin paths containing filesystem separators or traversal patterns. Database servers should also be monitored for outbound SMB and NFS connections that are unusual for their role.
- Alert on new or unexpected roles receiving the REPLICATION attribute.
- Review replication-slot creation events from unusual users or source IP addresses.
- Investigate plugin names containing path separators, parent-directory traversal, UNC paths, or unexpected absolute paths.
- Monitor outbound TCP/445 and NFS-related traffic from PostgreSQL servers.
- Review changes to
pg_hba.conf,postgresql.conf, andshared_preload_libraries. - Investigate unexpected native libraries loaded into the PostgreSQL process.
Risk Assessment
| Dimension | Assessment | Reason |
|---|---|---|
| Technical Impact | Critical impact potential | Arbitrary native code execution can cross from database privileges into operating-system execution |
| Network Reachability | Network | CVSS AV:N; attack can originate over a database connection when prerequisites are met |
| Authentication Requirement | Required | Attacker needs a valid PostgreSQL account with REPLICATION privilege |
| Privilege Requirement | High | PostgreSQL's official CVSS vector is PR:H |
| User Interaction | None | CVSS UI:N |
| Exploit Maturity | Functional researcher PoC | Cyera demonstrated the issue and supplied a Windows PoC during disclosure |
| Known Exploitation | Not confirmed | Malicious PostgreSQL plugins found in the wild do not establish exploitation of this CVE |
| Patch Availability | Available | Fixed supported releases were published by PostgreSQL |
| Overall Risk | High | Severe takeover potential is moderated by the requirement for a REPLICATION-privileged credential and platform-specific library-delivery conditions |
Although the resulting compromise can be severe, the official High rating is important to preserve. CVE-2026-6471 is not an unauthenticated internet-to-RCE vulnerability: the attacker must first obtain a privileged replication account. Organizations should nevertheless treat affected systems as high-priority remediation targets because successful exploitation can bypass the intended separation between database privileges and native server execution.
Patch and Mitigation
CVE-2026-6471 - PostGREShell
PostgreSQL fixed CVE-2026-6471 in 18.6, 17.11, 16.15, 15.19, and 14.24. Administrators running supported PostgreSQL branches should upgrade to these or later releases.
| Major Version | Fixed In | Official Fix Date |
|---|---|---|
| PostgreSQL 18 | 18.6 | August 13, 2026 |
| PostgreSQL 17 | 17.11 | August 13, 2026 |
| PostgreSQL 16 | 16.15 | August 13, 2026 |
| PostgreSQL 15 | 15.19 | August 13, 2026 |
| PostgreSQL 14 | 14.24 | August 13, 2026 |
For environments that cannot patch immediately, reduce exposure by removing REPLICATION privilege from accounts that do not require it, restricting replication connections in pg_hba.conf to known trusted sources, and limiting outbound network access from database servers. Cyera specifically recommends blocking outbound SMB (TCP/445) and NFS (TCP/UDP 2049) where those protocols are not required and disabling automounting services where they are unnecessary.
Remediation Recommendations
Immediate actions should upgrade supported PostgreSQL installations to 18.6, 17.11, 16.15, 15.19, or 14.24 or later. At the same time, enumerate all roles with REPLICATION privilege and remove that capability from accounts that do not have a current operational requirement.
Near-term actions should review pg_hba.conf for permissive replication rules, restrict replication connections to known hosts, block unnecessary outbound SMB/NFS traffic, inspect existing logical replication slots, and search for unusual plugin names or native libraries associated with PostgreSQL.
Long-term improvements should treat replication credentials as high-impact credentials rather than routine backup secrets. Store them in controlled secret-management systems, rotate them regularly, monitor their use, and segment database servers so they cannot freely access external file-sharing services. Organizations running unsupported PostgreSQL branches should also move to a supported release rather than relying on historical package maintenance alone.
Instantly Fix Risks with Saner Patch Management
Saner Patch Management is a continuous, automated, and integrated patch management solution that helps organizations rapidly remediate security risks across Windows, Linux, macOS, and a broad range of third-party applications.
The platform supports automated deployment workflows, patch testing, compliance reporting, and rollback capabilities to help reduce operational risk while keeping critical software updates moving quickly across enterprise environments.
Experience the fastest and most accurate patching software here.
