A database bug old enough to drink has just been patched. The PostgreSQL project released updates fixing 52 security flaws this week, and the most serious one is a type confusion vulnerability whose root cause dates back to May 2004. Tracked as CVE-2026-6460 and scored 8.8 out of 10 on the CVSS scale, it lets an attacker who can create objects in a database run code on the server itself. Here is what the flaw is, which versions are affected, and what database teams should do about it right now.
What CVE-2026-6460 Actually Is
CVE-2026-6460 is a type confusion flaw in the way PostgreSQL handles composite types. A composite type is a type built from named fields, where each field has its own data type. The problem is that a field’s type can be changed while older values of the previous type are still held in other parts of the server.
When that happens, the server could read an old value as if it had the new type. Security researcher Mehmet Ince worked out how to turn that mismatch into code execution and demonstrated a working exploit on PostgreSQL 18.6 in a technical writeup published this week. His method prepares a query that holds a value, changes the type of one of the value’s fields, and then runs the query. The writeup includes the SQL that crashes an unpatched server and a second step that leaks memory addresses.
Any code run through the flaw executes with the rights of the operating system user running PostgreSQL, which on many installations is a powerful service account. Ince wrote that he could trigger the crash as a lowest-privileged login role. The project’s advisory describes the attacker more broadly as someone who can create objects, and Red Hat’s assessment says an attacker needs a database login with the ability to create or modify objects. Whether a default-privilege account can push past the crash to full code execution is not settled in the public sources.
Why This Bug Is 22 Years Old
Ince traces the root of the flaw to 5 May 2004, the day PostgreSQL gained the ability to change a column’s type. That feature created the window where old values and new type definitions could drift apart. His technique for turning the mismatch into actual code execution relies on a later change made on 14 May 2015, which is why the flaw sat unnoticed through more than two decades of releases.
It is a good reminder that long-lived database code accumulates risk quietly. Features that were safe in isolation can interact with later changes in ways nobody re-audits, because the original code keeps passing its tests year after year.
Which Versions Are Affected
Every PostgreSQL release before these fixed versions is affected:
- PostgreSQL 18.7
- PostgreSQL 17.12
- PostgreSQL 16.16
- PostgreSQL 15.20
- PostgreSQL 14.25
The fix, described in the project’s release notes, adds version checks so the server can detect a value that no longer matches its type. There is one important catch: fully protecting a server also requires rebuilding any C-language extensions installed on it. Patching the binaries alone is not the complete remediation for installations with compiled extensions.
The Other 51 Flaws in the Release
PostgreSQL rates 32 of the 52 flaws at 8.8, the highest score in this release. A few are worth calling out beyond CVE-2026-6460:
- CVE-2026-116322: based on the project’s vulnerability index, this is the only flaw in the server that needs neither a login nor any user action. It lets an unauthenticated client trigger a restart of PostgreSQL 18 servers, which is a denial of service anyone on the network can attempt.
- pg_restore: a crafted archive can make pg_restore run code as the user running the tool, which matters for teams that restore from third party backups.
- psql via pg_dump output: a compromised source server can make psql run code through the restore script hidden in pg_dump’s tar output. This turns a backup migration from a compromised host into a client-side code execution path.
Together these fixes push the update from routine to urgent, especially for anyone who accepts database dumps or backup archives from other teams or systems.
What Managed Database Services Are Doing
Ince adapted his exploit for managed PostgreSQL services and privately shared proofs of concept with their security teams back in August. The providers he worked with include AWS (Aurora and RDS), Microsoft (Azure Database for PostgreSQL), Google (AlloyDB), Supabase, Databricks and Ubicloud. His writeup does not list each service’s current patch status, so customers on managed platforms should check their provider’s advisories directly rather than assuming the upgrade has already landed on their instance.
The PostgreSQL Global Development Group has not reported any attacks using the flaw, and CISA’s assessment in the CVE record also lists exploitation as none. The project credited more than a dozen reporters for CVE-2026-6460, including Ince, and credited him on five other flaws in the same release.
How to Check Your Version and Exposure
Before planning any downtime, confirm exactly what you are running. Connect with psql and run SELECT version();, which returns the full version string including the minor number. If that number is lower than the fixed release for your branch, schedule the update. Next, list compiled extensions with SELECT * FROM pg_available_extensions WHERE installed_version IS NOT NULL;. Any extension written in C needs a rebuild after the upgrade, and this query tells you how much work that is. Finally, review roles with SELECT rolname, rolcreaterole FROM pg_roles; to see which logins can create objects or hand that ability to others. On shared hosting platforms, this last list is often longer than the application actually needs.
What to Do Now
- Upgrade to the fixed branch release: move to 18.7, 17.12, 16.16, 15.20 or 14.25 depending on your major version. The version checks in the fix are the actual protection.
- Rebuild C-language extensions: after upgrading, recompile every C extension against the patched server. Skipping this leaves part of the exposure open.
- Audit who can create objects: the flaw needs create privileges to reach code execution. Roles with CREATE on schemas or databases should be reviewed and trimmed to what applications actually need.
- Treat backup archives as untrusted input: with the pg_restore and psql fixes in mind, only restore archives from sources you control, and update client tooling alongside the server.
- Ask your managed provider: if you run Aurora, RDS, Azure PostgreSQL, AlloyDB, Supabase or Databricks, confirm in writing that your instance has been patched.
- Watch for crash reports: the unauthenticated restart flaw and the crash step of the exploit share symptoms with ordinary outages. Correlate unexpected restarts with connection source addresses.
What is CVE-2026-6460
CVE-2026-6460 is a PostgreSQL type confusion vulnerability with a CVSS score of 8.8. It lets an attacker who can create database objects run code on the server with the permissions of the PostgreSQL service account. The root cause dates back to a feature added in May 2004.
Which PostgreSQL versions need the security update
All versions before PostgreSQL 18.7, 17.12, 16.16, 15.20 and 14.25 are affected. Update to the fixed release for your major version, then rebuild any C-language extensions to fully close the vulnerability.
Has CVE-2026-6460 been exploited in the wild
No attacks have been reported so far. The PostgreSQL project says it has no reports of exploitation, and CISA’s entry for the CVE lists exploitation as none. A working exploit method is public, so the window for staying unpatched is closing.
Do I need to patch pg_dump and psql as well
Yes. Two of the 52 fixes are in client tooling: a crafted archive can run code through pg_restore, and a compromised source server can run code on your machine through psql when you restore pg_dump tar output. Update client packages wherever your team dumps or restores databases.
