Mehmet Ince follows a question about PostgreSQL internals into a vulnerability in composite types, the structures that describe rows. His investigation shows what can happen when a value’s stored bytes and the metadata used to interpret them stop agreeing.

  • A prepared query held a composite value while a field’s type was changed from uuid to bytea.
  • The stored bytes were not rewritten, but PostgreSQL selected an output function using the new type. That function interpreted the old bytes as a different internal representation and crashed.
  • Ince traced the crash into an exploit involving forged internal objects and an information leak. He reports that a low-privileged login could trigger the original crash.
  • PostgreSQL’s November 9 security release included fixes. CVE-2026-6460 covers a broader family of composite-type problems, with multiple researchers credited.

The age of the bug needs care: Ince dates the mutable-row-type primitive to 2004, while the expanded-object feature used by his exploit arrived in 2015. Those are different parts of the chain.

The engineering lesson is about invariants across time. Cached or prepared data must still match the schema used to interpret it when execution finally happens.