PostgreSQL patches CVE-2026-6460, a 22-year-old type-confusion RCE

PostgreSQL shipped its quarterly updates on November 12, fixing CVE-2026-6460 — a type-confusion flaw that lets a database user who can create objects execute arbitrary code as the operating-system account running the server. The project scores it CVSS 8.8. The root cause dates to a 2004 commit, making this one of the longest-lived code-execution bugs the project has disclosed. If you run PostgreSQL and let any non-superuser create objects, patch now.

What the bug does

Per the PostgreSQL advisory for CVE-2026-6460, the server tracked typed values inadequately: values were not self-identifying, so a stale value of one type could later be read as if it had a different type. Stale values could linger in data-dictionary entries, PL/pgSQL variables, and elsewhere.

The primary path is ALTER ... SET DATA TYPE, but the advisory notes other DDL routes, such as:

ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN

The vector is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — network-reachable, low complexity, but requiring a login that can create or modify objects. Researcher Mehmet Ince, who reported it, traces the root to a May 2004 commit, with his code-execution technique relying on a 2015 change, according to The Hacker News.

Affected and fixed versions

All releases before 18.7, 17.12, 16.16, 15.20, and 14.25 are affected. The fixes shipped on November 12 in those versions (and in 19 RC 2). The 14 branch reaches end-of-life with 14.25 — the fix is in that final release, but migrate off 14 after applying it.

The same release bundles a large batch of other fixes — 52 flaws by The Hacker News's count; France's CERT-FR lists 53 CVE identifiers in its CERTFR-2026-AVI-1530 advisory. Patching the binaries is not the whole job: The Hacker News reports that full protection from CVE-2026-6460 also requires rebuilding any C-language extensions installed on the server, since extensions built against older releases still load but may not be fully protected.

Exploitation status

No in-the-wild exploitation has been reported. CISA's CVE record lists exploitation as none, and the flaw is not in the KEV catalog. The gating requirement — an account that can create objects — keeps this off the pre-auth scanners, but it is squarely a concern for multi-tenant databases, managed PostgreSQL that hands out CREATE rights, and anywhere application roles can define objects.

Action checklist

1. Apply the update for your branch (18.7 / 17.12 / 16.16 / 15.20 / 14.25) from the November 12 release.
2. Rebuild C-language extensions after updating; a patched server with an unrebuilt extension may still be exposed.
3. Audit who can create objects. Revoke CREATE on schemas from roles that do not need it; the bug is only reachable by accounts that can define or alter typed objects.
4. Prioritize multi-tenant and managed instances, where untrusted roles routinely hold object-creation rights.

Context

This is a server-core type-confusion bug, distinct from the PostgreSQL-adjacent flaws we have covered recently — the Splunk PostgreSQL sidecar RCE and the Drupal PostgreSQL SQL injection. Those were downstream integrations; this is the database engine itself. A 22-year dwell time is the notable part: the authenticated-and-object-creation precondition is why it survived undiscovered, and it is also why the patch urgency scales with how freely you hand out CREATE.