22-Year-Old PostgreSQL Bug Turned into Remote Code Execution

A security researcher’s investigation began with memory-corruption flaws in PostgreSQL extensions, including pg_clickhouse, where incorrect conversion of ClickHouse arrays into PostgreSQL values enabled code execution. After reporting that extension flaw and seeing it fixed, he turned to PostgreSQL’s own type system to understand how values are represented. He learned that a Datum is a generic carrier: its bytes do not identify their meaning, which PostgreSQL instead derives from type metadata such as an OID. The metadata also determines which native input and output functions process the value. An untyped string literal, for example, remains the special “unknown” type until context selects a final type.

That model suggested a way to cause type confusion: have PostgreSQL create a value under one type, then make it use a function expecting another. A superuser-created LANGUAGE internal function let him deliberately pair an integer with text’s native output routine, crashing the backend and demonstrating the danger of mismatched interpretation. The deeper discovery came from applying the same principle to composite values: change the declared type of a field after storing the row, then read it back using the altered layout. PostgreSQL interprets the existing bytes according to the new type, turning data into a pointer and yielding a reliable memory-corruption path to remote code execution. The flaw, CVE-2026-6460, had existed in PostgreSQL core for 22 years; the account follows how practical extension exploitation led to uncovering this long-standing primitive.