> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # 12-Year-Old PostgreSQL Vulnerability Enables Database, Server Takeover - URL: https://f4n6.co.uk/security-feed/12-year-old-postgresql-vulnerability-enables-database-server-takeover/ - Published: 2026-09-04T15:04:18.000Z - Updated: 2026-09-04T15:04:18.000Z - Author: Jeff Davies - Tags: #security-feed, CVE-2026-6471 ## 1\. Executive summary CVE-2026-6471 ("PostGREShell") is a missing-authorization flaw (CVSS 7.2 HIGH, CWE-862, **not** in CISA KEV, EPSS 0%) in PostgreSQL's logical decoding feature, present in every release since 2014 (versions 9.4 through 18; Cyera confirmed exploitation on 18.2). Any database account holding the `Replication` attribute — typically the credentials handed to backup tools, pipelines and monitoring utilities — can supply an arbitrary filesystem path as the output-plugin name, which is passed unsanitised to `dlopen()` and executed as the `postgres` OS user. The loaded code can then escalate to permanent database superuser and install a persistent backdoor. Patches exist in PostgreSQL 18.6, 17.11, 16.15, 15.19 and 14.24; EMEA financial services running PostgreSQL with logical replication enabled should treat replication-account hygiene as the immediate control and patch as the durable fix. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 24: digital operational resilience testing — general requirements | The vulnerable path exists by default wherever logical replication is enabled, and exploitation requires only a low-privilege replication credential — a configuration-level weakness that resilience testing should surface before exploitation. | Include replication-privilege audits and logical-decoding abuse cases in the Art. 24 testing programme; verify test coverage actually exercises the replication protocol path, not just application-layer SQL. | | DORA Art. 28: ICT third-party risk — general principles | The exploitable credential class (Replication-attribute accounts) is routinely provisioned to third-party backup, monitoring and data-pipeline tools, so the exposure is materially created by ICT third-party arrangements. | When assessing PostgreSQL-dependent third-party providers, require evidence that replication attributes are minimised and that provider-held replication credentials cannot reach plugin-loading paths. | No NIS2 or UK NIS article is directly engaged by the facts in this item: the source material describes a vulnerability and patch availability, not an incident affecting an entity in scope of those regimes. ## 3\. Technical analysis & attack chain ### Confirmed attack chain (per Cyera's disclosure) 1. **Initial access / credential position.** The attacker holds, or has compromised, a database account with the `Replication` attribute. Cyera characterises these as the credentials "nobody worries about" — one is provisioned to every connected backup tool, server, pipeline and monitoring utility. 2. **Replication protocol interaction.** The attacker connects via PostgreSQL's dedicated replication protocol and creates a logical replication slot, naming an output plugin to format the change stream. 3. **Path injection.** The plugin name is passed directly to the loader with no validation or sanitisation. The protocol parser accepts almost any character inside a double-quoted plugin name: forward slashes, backslashes, dots, `../` traversal, and Windows UNC paths. The attacker supplies a full filesystem path to any file visible to the OS account running the server. 4. **Arbitrary code execution.** The path is handed to `dlopen()`, which loads the file as a shared library. The plugin's init function runs with the privileges of the server process — the `postgres` OS user — in the same address space as PostgreSQL, with no sandbox and no checks on internal API calls. 5. **Privilege escalation to permanent superuser.** The loaded code calls an internal function to become the bootstrap superuser for the session, then writes directly to `pg_authid` — the catalog table defining superusers — and flips every privilege flag to true. This grants permanent superuser status: access to every table in every database, OS command execution, private-key reading, and file writes anywhere the `postgres` process can reach. 6. **Persistence.** The plugin can deploy backdoor mechanisms: enable passwordless connections, copy itself to a stable location and register itself to be re-loaded into every new backend, and re-apply the superuser change even if it is reverted. **Affected and fixed versions.** Affected: every version from 9.4 through 18 (confirmed on 18.2). Patched: 18.6, 17.11, 16.15, 15.19, 14.24\. The GitHub advisory (GHSA-8rqw-w7xq-566r) lists affected versions as those before 18.4, 17.10, 16.14, 15.18 and 14.23 — a slightly different cut, consistent with the same patch train; the fixed-version list above is Cyera's and is the more conservative (later) set. **Discrepancy note.** The GitHub advisory describes the underlying flaw as an integer wraparound causing an undersized allocation and out-of-bounds write, whereas the verified NVD data classifies CVE-2026-6471 as CWE-862 (Missing Authorization) and Cyera describes a missing-authorization path in logical decoding. Both descriptions are attached to the same CVE; the verified CWE-862 classification is authoritative here. Treat the integer-wraparound description as a second, related manifestation under the same identifier until NVD/GitHub reconcile. **Confidence caveat.** The full attack chain, the PostGREShell naming, and the persistence capabilities are single-sourced to Cyera's research as reported by SecurityWeek. ANSSI/CERT-FR (CERTFR-2026-AVI-0718) independently confirms a PostgreSQL vulnerability enabling privilege escalation, and the GitHub advisory corroborates the affected-version range and code-execution impact, but neither corroborates the specific dlopen/plugin-name mechanism or the backdoor behaviours. Verify before enforcement action predicated on those specifics. ## 4\. Mitigation & containment ### P1 — within 24 hours - **Inventory and audit replication accounts.** Enumerate all roles with the `Replication` attribute across every PostgreSQL instance: `SELECT rolname, rolreplication, rolsuper FROM pg_roles WHERE rolreplication OR rolsuper;`. Remove the attribute from any account that does not require it. This is the primary containment lever: without `Replication`, the logical-decoding path is closed. - **Restrict plugin loading.** Confirm `pg_authid` and admin-controlled plugin directories are not writable by any non-superuser or by the accounts used by third-party backup/monitoring tools. Verify no world-writable or tool-writable paths exist that the `postgres` OS user can read. - **Hunt for existing abuse.** Review `pg_replication_slots` for unexpected logical slots and unexpected output-plugin names — especially any slot whose plugin field contains a path, slash, backslash or UNC-style string. Check `pg_authid` for unexpected superuser flags and any accounts with passwordless (`trust`) authentication enabled. ### P2 — within 72 hours - **Patch.** Upgrade to PostgreSQL 18.6, 17.11, 16.15, 15.19 or 14.24 as appropriate to your branch. Instances on EOL branches (anything before 14) have no fixed release in the listed set and should be scheduled for migration, not indefinite mitigation. - **Credential rotation.** Rotate passwords for all replication-attribute accounts, on the assumption that these low-attention credentials are shared with third-party tooling and may be broadly known. - **Network containment.** Ensure the PostgreSQL port (default 5432) is not exposed beyond the backup/replication segment; replication connections should originate only from known hosts. ### P3 — within 7 days - **Third-party review.** Under DORA Art. 28, require backup, monitoring and pipeline vendors that hold replication credentials on your instances to confirm their credential scope and patch status. - **Resilience testing.** Add logical-decoding abuse (replication-credential to plugin-load) to the Art. 24 testing programme as a standing test case. ## 5\. Indicators of compromise No atomic indicators of compromise (hashes, domains, IPs, filenames) are available in the source material. Cyera's disclosure describes capabilities and mechanism but publishes no sample artefacts. ### Behavioural indicators | Behaviour | Where to observe | Confidence | | --------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------- | | Logical replication slot created with an output-plugin name containing a path, slash, backslash, .. traversal or UNC syntax | pg\_replication\_slots catalog; PostgreSQL logs | High (mechanism confirmed by Cyera; single-sourced) | | Unexpected superuser flag set on an existing or new role; all privilege flags flipped to true | pg\_authid / pg\_roles audit | High (single-sourced to Cyera) | | Passwordless authentication newly enabled on an account | pg\_hba.conf; pg\_authid password fields | Medium (single-sourced to Cyera) | | Shared library re-loaded into every new backend from a stable filesystem location | PostgreSQL logs (plugin load messages); filesystem monitoring on the data/plugin directories | Medium (single-sourced to Cyera) | | Replication-protocol connections from backup/monitoring tooling outside expected hosts or schedules | PostgreSQL connection logs; network telemetry on port 5432 | Medium (inferred from the access requirement) | ## 6\. Detection ```yara rule PostgreSQL_PostGREShell_Suspicious_Plugin_Load { meta: author = "Adverse Trace" date = "2026-09-04" reference = "https://www.securityweek.com/12-year-old-postgresql-vulnerability-enables-database-server-takeover/" description = "Detects suspicious output plugin names passed to the PostgreSQL logical decoding loader via CVE-2026-6471 (PostGREShell)." strings: $plugin_quote = "CREATE_REPLICATION_SLOT" $unc_path = "\\\\" $traversal = "../" $dlopen = "dlopen" condition: 2 of them } ``` Note: the strings above are drawn from the protocol verb and path syntaxes described in the source; no malicious sample binary was published, so this rule targets the loading pattern rather than a specific payload. Treat hits as investigative leads, not confirmed compromise. ```yaml title: PostgreSQL logical replication slot created with path-like output plugin name id: 7b2c1b6e-4d3a-4f5e-9a8b-1c2d3e4f5a6b status: experimental description: Detects creation of a logical replication slot whose output plugin name contains filesystem path syntax, consistent with CVE-2026-6471 (PostGREShell) abuse. references: - https://www.securityweek.com/12-year-old-postgresql-vulnerability-enables-database-server-takeover/ tags: - attack.persistence - attack.privilege_escalation logsource: product: postgresql service: database detection: selection: message: - '*CREATE_REPLICATION_SLOT*' filter_plugin_path: message: - '*.so*' - '*../*' - '*\\*' condition: selection and filter_plugin_path falsepositives: - Legitimate plugins referenced with explicit paths in non-standard deployments level: high ``` ## CVE assessment 1 referenced CVE | CVE | CVSS | Exploited | EPSS | Summary | | ------------------------------------------------------------------------------ | -------- | --------- | ---- | -------------------------------------------------------------------------------------------------------------------------------- | | [CVE-2026-6471](https://nvd.nist.gov/vuln/detail/CVE-2026-6471?ref=f4n6.co.uk) | 7.2 High | — | 0% | Missing authorization in PostgreSQL logical decoding allows a non-superuser holding REPLICATION privilege to dlopen any file vi… | ## 7\. Sources - SecurityWeek — "12-Year-Old PostgreSQL Vulnerability Enables Database, Server Takeover" — https://www.securityweek.com/12-year-old-postgresql-vulnerability-enables-database-server-takeover/ — 2026-09-04 - ANSSI France CERT (CERT-FR) — "Vulnérabilité dans PostgreSQL" (CERTFR-2026-AVI-0718) — https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0718/ — 2026-06-10 - GitHub Security Advisories — "Integer wraparound in multiple PostgreSQL server features allows an unprivileged database user to cause the server to undersize an allocation and write out-of-bounds" (GHSA-8rqw-w7xq-566r) — https://github.com/advisories/GHSA-8rqw-w7xq-566r — undated ## 8\. Adverse Trace position CVE-2026-6471 is a CVSS 7.2 HIGH missing-authorization flaw, not yet in CISA KEV and with EPSS at 0%, but the preconditions — a 12-year exposure window, a credential class provisioned by default to third-party tooling, and a code-execution-to-persistent-backdoor outcome — make it a priority for any EMEA financial services firm running PostgreSQL with logical replication, which is now standard production plumbing. The CVSS score understates operational impact: superuser compromise of a core database is a direct route to data access and OS-level execution on the database host. The detailed mechanism and backdoor capabilities are single-sourced to Cyera and should be verified before enforcement action, but the version range and patch availability are corroborated by GitHub's advisory and the exposure is corroborated by CERT-FR. We will monitor for KEV listing, EPSS movement, and any published exploitation or sample artefacts, and will reissue if the integer-wraparound versus missing-authorization classification resolves differently or if in-the-wild abuse surfaces. --- [Read the original source →](https://www.securityweek.com/12-year-old-postgresql-vulnerability-enables-database-server-takeover/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*