PostgreSQL ships biggest security release in years, fixing 52 flaws and a 22 year old RCE bug

On November 12, 2026, the PostgreSQL Global Development Group released PostgreSQL 18.7, 17.12, 16.16, 15.20 and 14.25, together with a second release candidate of PostgreSQL 19. The update covers every supported branch of the database at once, and it fixes 52 security vulnerabilities plus more than 140 bugs reported over the last several months. For a project that normally ships small, predictable minor releases, that is an unusually heavy batch.

The release also ends a chapter. The PostgreSQL Global Development Group announced on November 12 that 14.25 would be the final release of PostgreSQL 14, which is now end-of-life. Servers still running that branch will receive no further security or bug fixes, and the announcement urges administrators with 14 in production to plan an upgrade to a supported version. That deadline is not new, but it lands in the same week as the largest vulnerability batch of the year, which makes the overlap harder to ignore.

The most serious entry is CVE-2026-6460, a type confusion flaw that lets a database user who can create objects run code with the rights of the operating system user behind PostgreSQL. The official advisory names ALTER ... SET DATA TYPE as the primary route, notes that other DDL paths exist, and explains that the system tracked typed values inadequately and values were not self-identifying, so stale values could surface in data dictionary entries, PL/pgSQL variables and many other parts of the system.

The age of the bug gives it narrative weight. The Hacker News reported on November 13 that researcher Mehmet Ince published a working exploit demonstrated on PostgreSQL 18.6 and traced the root cause to May 5, 2004, when PostgreSQL first gained the ability to change a column type. His path to code execution leans on a separate change made on May 14, 2015. Ince also adapted the exploit for managed PostgreSQL services and privately shared proofs of concept with their security teams in August.

Key Facts

Every branch before 18.7, 17.12, 16.16, 15.20 and 14.25 is affected. CVE-2026-6460 carries a CVSS 3.1 score of 8.8, with the vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, and the advisory maps the 18, 17, 16, 15 and 14 branches to their fixed releases, all published on November 12.

The batch is not a single flaw surrounded by noise. Six other entries also score 8.8: CVE-2026-18447, output parameter type confusion; CVE-2026-116304, a parallel RECORD typmod use-after-free; CVE-2026-116306, a composite-type change during field assignment; CVE-2026-116314, pg_restore missing non-plain archive validation, which requires user interaction; CVE-2026-116318, SQL injection through a not-null constraint name in pg_dump; and CVE-2026-116330, psql command injection through the pg_dump tar restore script. CVE-2026-6467, extension script schema mishandling, is rated 7.2.

In total, 32 of the 52 flaws score 8.8, the highest rating in the release, while the lowest reaches 3.1 for a way around the EXECUTE privilege on cast functions. The PostgreSQL Global Development Group has not reported any attacks using CVE-2026-6460, and the CISA assessment in the CVE record lists exploitation as none. The Hacker News reported on November 13 that only one flaw, CVE-2026-116322, requires neither a login nor user action, letting an unauthenticated client trigger a restart of PostgreSQL 18 servers.

The fixes span PL/Perl, PL/Tcl, text search functions such as ts_rank_cd(), parallel query, logical replication, dblink and statistics import. Most of the code execution bugs are memory errors or type confusion, where PostgreSQL handles a value as the wrong data type. The project credits more than a dozen reporters for CVE-2026-6460. Administrators must update the server and rebuild or update every C-language extension at the same time, because extensions built against older releases still load but may not be protected, and some need source changes as well.

The PostgreSQL Global Development Group added on November 12 that several fixes require follow-up work. GIN indexes suspected of corruption should be reindexed, as should pg_trgm GiST indexes using gist_trgm_ops and B-tree indexes on bpchar columns declared without a length, while tables throwing missing chunk number errors need REINDEX TABLE. Because several fixed bugs could produce corrupt backups, existing incremental backups should not be trusted and a new full backup should be taken. PostgreSQL 19 RC 2 also shipped, reverting support for JSON_ARRAY() and JSON_OBJECT() over arrays, composite types and range types in expression indexes, generated columns and partition keys, with general availability planned for November 19.

Analysis

What this really means is that the line between a low-privilege database account and the host operating system has become far thinner than most deployment checklists assume. An object creator is not an administrator. In many teams that role is handed to application schemas, migration users or third-party tooling precisely because it is considered contained. CVE-2026-6460 makes that assumption expensive, since the same permission now reaches code execution as the postgres operating system user.

The score distribution reinforces the point. With 32 of 52 flaws at 8.8, this is not a release where a single bad CVE sits on top of routine hardening. Help Net Security reported on November 13 that the lowest score in the batch is 3.1 and that the fixes reach client tools as well as the server, including a SQL injection through not-null constraint names in pg_dump and a psql command injection in its tar-format restore script. Teams that patch servers but leave client binaries untouched are only half protected.

The extension problem is the part most likely to be mishandled. A patched server with unpatched C-language extensions can report a clean version string while still loading code built against vulnerable internals. That creates a false sense of closure, and it turns a routine minor upgrade into a rebuild exercise that requires knowing which extensions are installed, where their sources live and whether they need changes.

The PostgreSQL Security Advisory published on November 12 confirms the affected and fixed version mapping directly, which leaves little room for ambiguity about eligibility. The absence of observed exploitation is still not reassurance. No attacks have been reported, but the exposure is real regardless, and a flaw rooted in 2004 that only now has a public exploit is a natural target for scanning.

Why It Matters

PostgreSQL sits behind a large amount of application infrastructure, and the affected range covers every supported branch before the November 12 releases. The managed providers that received private proofs of concept in August include AWS with Aurora and RDS, Microsoft with Azure PostgreSQL, Google with AlloyDB, Supabase, Databricks and Ubicloud. Those teams had warning; the long tail of self-managed deployments did not. For that audience, the practical question is not whether the flaw is exploitable in theory but whether the object creation privilege is handed out more freely than anyone intended.

PostgreSQL 14 reaching end-of-life compounds the problem. Version 14.25 is the last release of that branch, so any server that stays on 14 after this update is frozen at a point in time while new flaws keep arriving. Planning an upgrade is now a security requirement rather than a housekeeping preference.

The operational follow-up matters as much as the install. Reindexing affected index types, taking a fresh full backup and rebuilding extensions are all steps that can be skipped under time pressure, and each one leaves a residual failure mode that can look like success. None of these steps is technically difficult; the risk is coordination across teams that own different pieces of the same stack.

Next Up

PostgreSQL 19 RC 2 arrived alongside the security batch, and general availability is planned for November 19. The second release candidate reverts support for JSON_ARRAY() and JSON_OBJECT() over arrays, composite types and range types in expression indexes, generated columns and partition keys, a change worth checking before any upgrade rehearsal. The timing matters for anyone mid-migration, since testing against a candidate that later changes behaviour wastes effort.

For administrators, the sequence is clear: move every server to 18.7, 17.12, 16.16, 15.20 or 14.25, rebuild or update each C-language extension, reindex the flagged index types, take a new full backup, and treat PostgreSQL 14 as a migration project rather than a patched system.