Loading story…
CVE-2026-6471 (“PostGREShell”) is a CVSS 7.2 missing-authorization flaw in PostgreSQL logical decoding that lets a non-superuser account with the REPLICATION privilege provide an arbitrary filesystem path as an output-plugin name. PostgreSQL then loads the selected shared library via dlopen() and executes it as the postgres operating-system user, enabling database-server takeover.
The vulnerability reportedly existed since PostgreSQL 9.4 and affects releases through PostgreSQL 18 before remediation. Exploitation can yield operating-system command execution, permanent PostgreSQL superuser escalation, access across databases, accessible private-key theft, and persistent backdoors. PostgreSQL fixed the issue in versions 18.6, 17.11, 16.15, 15.19, and 14.24; organizations should update affected deployments and review or remove unnecessary REPLICATION privileges.
Get the actors, campaigns, and ATT&CK mapping behind it.
4 events from the most recent confirmed update back to the earliest known activity.
PostgreSQL 13 reached end of life and no longer receives upstream security fixes. Consequently, PostgreSQL 13 deployments affected by CVE-2026-6471 do not receive an upstream PostGREShell patch.
The missing-authorization flaw in PostgreSQL logical decoding, later designated CVE-2026-6471 (PostGREShell), was reportedly present from PostgreSQL 9.4 in 2014.
PostgreSQL addressed PostGREShell in versions 18.6, 17.11, 16.15, 15.19, and 14.24. The flaw affected releases from version 9.4 through affected builds prior to those fixed versions.
Cyera researchers identified and reported CVE-2026-6471, which allows a non-superuser with the REPLICATION attribute to supply a malicious logical-decoding plugin path and execute code as the PostgreSQL server operating-system user.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
8 references tracked. Mallory keeps watching after this page renders.
cybersecuritynews.com
Open sourcecryptika.com
Open sourcethecybersecguru.com
Open sourcescworld.com
Open sourcethehackernews.com
Open sourcesecurityaffairs.com
Open sourcesecurityweek.com
Open sourcecyera.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A critical flaw in **StackGres** allowed a low-privilege tenant who owns a PostgreSQL database to escalate to **remote code execution** in the primary PostgreSQL pod through the platform’s default metrics exporter. The issue was reported by **Cipher** of Causal Security and tracked in GitLab as a tenant `DB-owner` to pod RCE path affecting StackGres **1.x through 1.18.8** and the referenced `1.19.0-SNAPSHOT` build. According to the report, the exporter connected as the cluster superuser and, during Prometheus scrapes, opened superuser `dblink` sessions into tenant databases. The exploit relied on the exporter executing remote SQL with unqualified object references while failing to pin `search_path`, allowing an attacker to set a database-level `search_path` and create shadow objects such as a malicious `version()` function. When the exporter’s superuser session resolved those objects, it could be driven into attacker-controlled execution and ultimately reach PostgreSQL primitives such as `COPY ... TO PROGRAM` for operating-system command execution inside the pod. The vulnerability was later discussed as fixed and released in **StackGres 1.19.0 GA**, and a **CVE** request was subsequently submitted through GitLab’s process.
Aug 23, 2026
A critical remote code execution vulnerability, tracked as CVE-2025-13780, was discovered in *pgAdmin 4*, the widely used open-source PostgreSQL database management tool. The flaw allows attackers to bypass security filters in the plain-text restore feature by inserting unexpected whitespace characters, enabling the execution of arbitrary shell commands on the host server through maliciously crafted SQL dump files. The vulnerability affects pgAdmin 4 versions prior to 9.11 and was found to stem from an inadequate regular expression filter that failed to block dangerous commands effectively. Security researchers at EndorLabs identified the issue and reported that attackers could exploit this weakness to gain unauthorized access and potentially take over affected servers. In response, the pgAdmin development team released version 9.11, which implements the `\restrict` command to disable hazardous operations during the restore process, fundamentally improving the security model by enforcing restrictions at the execution level rather than relying solely on input filtering. Users are strongly advised to update to the latest version to mitigate the risk of exploitation.
Jun 29, 2026
PostgreSQL has released security updates for all supported branches after fixing **28 vulnerabilities**, including several high-severity flaws that could lead to remote code execution or full compromise of database instances. Patched versions are **14.24**, **15.19**, **16.15**, **17.11**, and **18.6**. Among the most serious issues are **`CVE-2026-14662`**, an out-of-bounds write involving the `tsvector` and `tsquery` data types, and **`CVE-2026-18408`**, which can enable code execution during the database restore process. Additional high-impact bugs disclosed in the same release include **`CVE-2026-14669`**, a heap buffer overflow in `to_char(timestamptz)` triggered by long POSIX timezone abbreviations and rated **CVSS 8.8**, and **`CVE-2026-14679`**, an argument-matching flaw that permits controlled out-of-bounds writes on the stack and carries a **CVSS 8.2** score. Successful exploitation of these vulnerabilities could allow attackers to execute code as the operating-system user running PostgreSQL. PostgreSQL said it had no reports of active exploitation at publication time and also warned that support for **PostgreSQL 14** ends on **November 12, 2026**, after which it will no longer receive security fixes.
Aug 20, 2026