PostgreSQL patched a 22-year-old type-confusion bug with code execution

A low-privilege PostgreSQL account that can create its own data types just became a much bigger problem. The bug under the account is 22 years old and sat in the default install for most of that time.

PostgreSQL released patches on 9 November for CVE-2026-6460, a type-confusion bug. The bug lets an unprivileged user run code on the database server. The writeup is by Mehmet Ince on mehmetince.net. It ranks 58 points on Hacker News at the time of writing. Ince says the primitive behind the bug dates to May 2004. PostgreSQL 18.6 and every earlier version are affected. The patched release is part of a set of 52 CVEs fixed on the same day.

What the bug lets an attacker do

The attack chain is three steps. The attacker creates a composite type that holds a UUID field. They prepare a query that stores controlled UUID bytes in that field. They then use ALTER TYPE to change the field from UUID to bytea. When the query runs, PostgreSQL reads the stored bytes with the new type's rules. It treats the UUID bytes as a bytea varlena header. From there, the attacker forges an ExpandedObjectHeader and ExpandedObjectMethods. That lets them hijack a function pointer. The code then runs as the PostgreSQL backend user.

Ince summarises the trick in his own words. He gave PostgreSQL a value inside a composite type. He then changed the type of one of its fields. Then he asked PostgreSQL to read the value back. The exploit works on a default install. No special configuration is needed. The only prerequisite is an account that can create temporary types and prepared statements. That is the default for any PostgreSQL role, unless the database owner has removed it.

The disclosure timeline, and the managed database question

Ince shared the exploit with cloud vendors in August 2026. He names Databricks, Google AlloyDB, Supabase, AWS Aurora and Azure in the list of vendors notified. The public patch landed on 9 November 2026 with the broader set. The five related CVEs are CVE-2026-120142, CVE-2026-120148, CVE-2026-116329, CVE-2026-116306 and CVE-2026-120139.

A team on a managed database will usually not run the upgrade itself. The host runs it. The question for a team on AWS Aurora, Google AlloyDB or Supabase is which release the host now runs. The next question is whether the host has a maintenance window planned. On a self-hosted PostgreSQL, the team runs the upgrade itself.

What to do this week

Four steps, in order. Patch to the 9 November release on every self-hosted PostgreSQL. Audit which roles can create composite types. On most installs, that includes any ordinary user unless the owner has revoked the right. Alert on ALTER TYPE operations in production. That is the step that turns the primitive into an exploit. Restrict temporary type creation on managed instances if the host permits it.

The bug reads as a database-internal issue and is, in practice, a shared-service one. A SaaS product may give each tenant its own PostgreSQL role on a shared instance. It now has to assume any tenant is untrusted at the database layer. A classic three-tier app with one application user that opens connections has a smaller surface. But the application user still has the right to create composite types by default.

Source

• Mehmet Ince, How I ended up turning a 22-year-old PostgreSQL type confusion primitive into RCE CVE-2026-6460.
• Hacker News discussion, 22-Year-Old PostgreSQL Bug Turned into Remote Code Execution.