PostgreSQL 18.7 Fixes CVE-2026-6460, a Type Confusion That a Researcher Turned Into Code Execution

An authenticated PostgreSQL user who can change a column or attribute type can make the server misread stored bytes and run commands as the operating-system account that owns the database. The project fixed it on November 12 in PostgreSQL 18.7, 17.12, 16.16, 15.20 and 14.25, and tracks it as CVE-2026-6460.

The security page rates it 8.8 (High) with the vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Every branch from 14 through 18 is affected. The page lists no exploitation in the wild and no workaround other than patching.

What the advisory says an attacker needs

The advisory describes the flaw as type confusion after ALTER ... SET DATA TYPE. Values were not self-identifying, so stale values could survive in data dictionary entries and PL/pgSQL variables after a type changed. The page also names other routes, such as ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN.

Its precondition is that the attacker is an object creator. Until patching, the page suggests limiting who can create tables, functions and types and who can run DDL.

Branch	Fixed in	Support status
18	18.7	Supported
17	17.12	Supported
16	16.16	Supported
15	15.20	Supported
14	14.25	Final release, end of life

The researcher's account is broader

Mehmet Ince, who is credited as a reporter in the PostgreSQL commit according to his write-up, says the crash can be triggered by "the lowest-privileged login role on any PostgreSQL instance." That is a different precondition from the advisory's.

The two statements may be reconcilable, since a login role with CREATE rights on any schema is an object creator. The advisory does not say how many default configurations grant that. Treat the score as a floor: PR:L is the vector, and the real exposure depends on who holds CREATE.

Ince describes the chain in four steps. A composite type is created with a UUID attribute and a prepared query returns it. ALTER TYPE then changes the attribute to bytea without rewriting stored bytes. During EXECUTE, byteaout() reads attacker-chosen bytes as a varlena header, and a header beginning 01 is treated as an external expanded-object reference. A forged object header then routes a method call to system(). He demonstrated it on PostgreSQL 18.6.

His post dates the underlying mutable row-type behaviour to a commit of May 5, 2004, and says he contacted vendors in mid-August 2026. He also writes that the patch commits landed on November 9, three days before the release, and calls CVE-2026-6460 "the main umbrella fix for type confusion."

What else the release changes

The November 12 release announcement says the update fixes more than 140 bugs. It lists several index-corruption fixes that need a reindex after updating, including GIN indexes, pg_trgm GiST indexes and B-tree indexes on bpchar columns without a length. Minor-version updates do not need a dump and restore.

PostgreSQL 14 gets no further fixes after 14.25. Operators on 14 who cannot move to a supported branch have no patch path for this flaw beyond that release.

Next on the calendar is PostgreSQL 19, planned for general availability on November 19. Everyone else should schedule the minor update and review who holds CREATE privileges. For other recent patch-or-else cases, see the OpenSSH bypass on Alpine and the GPUStack auth bypass.