The PostgreSQL Global Development Group shipped security updates on November 12 for all five supported major versions, issuing fixes for 52 vulnerabilities at once: the largest security release the project has published. Thirty-two of the 52 flaws carry a CVSS 3.1 score of 8.8, with no user interaction required, full confidentiality and availability impact, and network reachability through a low-privilege login. The fixed releases are 18.7, 17.12, 16.16, 15.20, and 14.25.
At the center of the batch is CVE-2026-6460, a type confusion flaw in how PostgreSQL handles composite types — data structures built from named fields. When a field's type is changed after values of the original type are already stored, PostgreSQL's binary representation keeps those old bytes intact while the catalog metadata shifts around them. The server then reads a stale value through the new type's output function. That mismatch is enough for a database user who can create objects to run arbitrary code as the OS account running PostgreSQL, no superuser status, no extensions, no file access.
The trigger takes exactly four SQL statements. A user creates a composite type, prepares a query using it, alters the attribute to a different type, then executes the prepared query. The backend selects the wrong output handler, dereferences a null pointer, and crashes. That crash is the entry point.
Security researcher Mehmet Ince found the flaw and published a writeup alongside a demonstration on PostgreSQL 18.6. He traces the root cause to a commit made May 5, 2004, the one that added ALTER TABLE ... ALTER COLUMN ... TYPE. That logic never accounted for prepared statements holding values built against the old type. The code sat there for 22 years. His exploit chain defeats ASLR through a related confusion involving PostgreSQL's unnest() function, then calls system() through a forged object whose methods table points at the system call. He stopped short of publishing that final step. He found 21 variants of the problem in total, and six of the 52 CVEs in this release trace to his work. The release credits 18 researchers for CVE-2026-6460 alone, including PostgreSQL core developers Heikki Linnakangas and Andres Freund, along with the OpenAI Security Research Team and the Anthropic OSS program.
Before going public, Ince spent August coordinating with every major managed provider. He shared working proofs of concept with AWS covering both Aurora and RDS, Microsoft for Azure Database for PostgreSQL, Google for AlloyDB, Supabase, Databricks, and Ubicloud. Google AlloyDB escalated the report to its highest internal priority. Databricks validated the exploits the same day they arrived. Several vendors deployed their own mitigations before the upstream release shipped. Their current patch status is not public, so administrators on managed services should verify the minor version their provider is running.
The release also contains a flaw that skips authentication entirely. CVE-2026-116322, rated 5.3, lets any client restart a PostgreSQL 18 server without logging in. It involves a cancel request and a spinlock held during the authentication timeout window. Two further vulnerabilities sit in the client tools: a crafted archive fed to pg_restore can execute code as whoever invoked it, and a compromised source server can inject commands through the restore script inside pg_dump's tar output to any psql client connecting to it.
The November release permanently closes the PostgreSQL 14 branch. Version 14.25 is its last update. Administrators still on that version are running unsupported software from today. PostgreSQL 15 reaches the same status in November 2027.
Upgrading involves more than swapping binaries. The fix for CVE-2026-6460 changes the server's internal ABI for C-language extensions, which must be rebuilt against the patched version. Extensions compiled for the new release will not load on an unpatched server, so the upgrade and the rebuild must happen together. A new server setting, composite_type_mismatch, enables the type-version checks behind the fix; the project says disabling it carries security risk. Client tools must be updated on every machine running them, not just servers. Clusters managed by Patroni or any custom service unit need a manual restart. Users of incremental backups should take a new full backup before anchoring further incrementals. No workaround exists for the principal vulnerability on servers that cannot be patched, and PostgreSQL has reported no attacks in the wild.
The same acknowledgment list that names Ince, Linnakangas, and Freund also includes AI-assisted tooling. That dynamic cuts both ways. PostgreSQL 19, normally shipped in September or October, was pushed to November 19 partly because AI and LLM tools generated enough new reports to overwhelm the maintainers' review capacity before the feature freeze. Developer Robert Haas noted that LLM-drafted patches still need human review to meet project standards, and consultant Christophe Pettus pointed to the volume of low-quality machine-generated reports as a growing burden. The same tools that surfaced a 22-year-old bug made it harder to ship the next version.
