CVE-2026-6460, a type‑confusion flaw with a CVSS score of 8.8, lets a database user who can create objects run code on the PostgreSQL server — and the project’s update this week fixes that bug along with 51 other security flaws.
CVE-2026-6460: how composite types became an authenticated RCE
The vulnerability tracked as CVE-2026-6460 stems from PostgreSQL’s handling of composite types — user-defined records built from named fields, each with its own data type. The server could read an older value as if it had a changed field type, allowing a type confusion condition that an attacker can turn into code execution. Any code run in this way inherits the rights of the operating‑system user that runs PostgreSQL.
All versions before 18.7, 17.12, 16.16, 15.20, and 14.25 are affected. The PostgreSQL Global Development Group has not reported any attacks using the flaw, and the CISA assessment listed in the CVE record marks exploitation as none.
Mehmet Ince’s exploit, timeline, and responsible disclosure
Security researcher Mehmet Ince published a technical writeup demonstrating a working exploit on PostgreSQL 18.6. His method prepares a query that holds a value, changes the type of one of the value’s fields, then runs the query; the writeup includes SQL that crashes unpatched servers and a second step that leaks memory addresses. It does not include the final SQL that makes the server run a command.
Ince wrote that he could "trigger this crash as a lowest‑privileged login role." He traces the root of the flaw to a May 5, 2004 change that added the ability to change a column’s type and says his technique relies on a later change made May 14, 2015. He privately shared proofs of concept with managed‑service security teams in August, including teams at AWS (Aurora and RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks, and Ubicloud; the writeup does not state each service’s current patch status.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildRelease scope: 52 fixes and other high‑severity issues
The Global Development Group released updates that fix 52 security flaws. Thirty‑two of those are rated 8.8 — the highest score in this release. One flaw, CVE-2026-116322, requires neither a login nor user action and lets an unauthenticated client trigger a restart of PostgreSQL 18 servers.
Several client tools were fixed as well: a crafted archive can make pg_restore run code as the user running it, and a compromised source server can make psql run code through the restore script in pg_dump’s tar output. The project credits more than a dozen reporters for CVE-2026-6460 and lists Mehmet Ince among the reporters credited on five other flaws in the release.
What administrators should do right now
- Update the server to the matching minor release: 18.7, 17.12, 16.16, 15.20, or 14.25.
- Rebuild or update every C‑language extension at the same time as the server. The project’s RPM package maintainers warn that extensions built against older releases still load but "may not be protected from the vulnerabilities fixed in this release," and some extensions will need source‑code changes.
- Be aware that extensions rebuilt for the new releases can fail to load on older servers; extension packages in the project's RPM repositories now require the new minor release.
- If PostgreSQL runs outside its package’s own service unit (for example, under Patroni), restart it immediately after updating, per an RPM packaging blog post.
- Update client tools — pg_dump, pg_restore, reindexdb and vacuumdb — on every machine that runs them.
- Do not disable the new checks with the composite_type_mismatch setting; the project says doing so carries security risks.
- Follow the reindexing steps in the release announcement and, if you use incremental backups, take a new full backup and base later incremental backups on it.
How managed‑service operators, security teams, and enterprise DBAs are affected
Managed‑service operators and cloud providers must validate both engine updates and any bundled or customer‑installed C extensions; Ince’s outreach to AWS, Microsoft, Google, Supabase, Databricks, and Ubicloud indicates providers were given proofs of concept but the public writeup does not list each provider’s patch status.
Security teams should prioritize the stated minor releases and rebuild C‑language extensions at the same time as servers to avoid running binaries compiled against older releases that "may not be protected." Red Hat’s CVE assessment frames the privilege needed as a database login able to create or modify objects, but neither the project nor Red Hat says whether a default‑privilege account can progress from a crash to code execution.
Enterprise DBAs must also update client tooling and follow the release’s reindexing and backup guidance. PostgreSQL 14 is end‑of‑life and 14.25 is its last release; administrators running older major versions received no update in this cycle.
PostgreSQL’s updates close a long‑standing, deep bug chain rooted in 2004 and shaped by a 2015 change. Administrators who cannot update immediately have no project‑provided workaround, and the fixes require careful coordination — especially where C extensions and managed services are involved. The immediate, practical questions are simple: apply the minor release that matches your major version; rebuild extensions; and refresh backups and reindexes as the release notes prescribe.
