PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25 fix 52 CVEs; 14 is end-of-life

The PostgreSQL Global Development Group released PostgreSQL 18.7, 17.12, 16.16, 15.20 and 14.25 on 12 November 2026, a single update that closes 52 security vulnerabilities and more than 140 other bugs. It is also the final release of PostgreSQL 14, which is now end-of-life. Because every supported branch is affected and the fix is a minor-version swap of the binaries, anyone who runs PostgreSQL with logins they do not fully trust should schedule the update now, and plan a few reindexing and backup steps afterwards.

Key points

• PostgreSQL 18.7, 17.12, 16.16, 15.20 and 14.25 (plus 19 RC 2) were released on 12 November 2026 and fix 52 security vulnerabilities and over 140 bugs, according to the project's announcement.
• By our count of the scores in the announcement, 35 of the 52 CVEs are rated CVSS 8.0 or higher (32 of them 8.8), 3 are 7.2 and 14 are between 3.1 and 6.5.
• PostgreSQL 14 reaches end of life with 14.25: no further security or bug fixes will be released for it.
• No dump and reload or pg_upgrade is needed, but the project says some fixes require reindexing (GIN, pg_trgm GiST, bpchar B-tree) and a fresh full backup if you use incremental backups.
• PostgreSQL 19 is planned for general availability on 19 November 2026; RC 2 includes the same fixes.

What to do

• Update to the latest minor release of your branch: 18.7, 17.12, 16.16, 15.20 or 14.25. Updates are cumulative, so you do not need to apply earlier ones first. Stop the server, replace the binaries, start it again.
• Check your version: run SELECT version(); or psql --version. Anything below the numbers above is affected.
• Prioritise clusters where roles you do not fully trust can log in or create objects, shared clusters, servers with PL/Perl, PL/Tcl or dblink installed, and subscribers whose logical replication subscription is owned by a superuser (CVE-2026-120145). The third-party write-up from ComputingForGeeks adds that hosts that run pg_restore or psql on dumps from other parties should get the new client package first (CVE-2026-116314 and CVE-2026-116330).
• After updating, follow the project's list: reindex GIN indexes you suspect are affected (REINDEX INDEX your_index_name;), reindex any GiST index using gist_trgm_ops if you use pg_trgm, reindex tables that show "missing chunk number" errors (REINDEX TABLE your_table_name;), and reindex B-tree indexes on columns declared as bpchar without a length (columns declared char(n) are not affected).
• If you use incremental backups, take a new full backup after updating and base later incrementals on it. The release notes say existing incremental backup files should not be trusted.
• If you are on PostgreSQL 14, this is the last fix you will get. Plan the move to a supported major version.
• Extensions: the release notes say that for full protection against composite-type changes, C-language extensions need to be rebuilt, and some will need source changes.

What happened

The PostgreSQL project published the update on 12 November 2026 together with the second release candidate of PostgreSQL 19. The announcement lists 52 CVEs. Most of them are memory-safety and type-confusion bugs: the titles of the high-scoring entries read like a catalogue of use-after-free, heap overflow and "type confusion executes arbitrary code" problems in different parts of the server.

Examples from the announcement, with the scores the project gives:

• CVE-2026-6460, rated 8.8: type confusion after ALTER ... SET DATA TYPE executes arbitrary code.
• CVE-2026-116304, rated 8.8: a use-after-free in parallel RECORD typmod use.
• CVE-2026-116315, rated 8.8: a heap buffer overflow in tsvector_delete().
• CVE-2026-116318, rated 8.8: a pg_dump not-null constraint name allows SQL injection.
• CVE-2026-116325, rated 8.0: reindexdb index name quoting allows SQL injection.
• CVE-2026-120145, rated 8.8: logical replication can write to subscriber system catalogs, executing arbitrary code.
• CVE-2026-116322, rated 5.3: a pre-authentication cancel request can leak a spinlock.

Several of the bugs sit in the procedural languages and client tools. The PL/Perl language alone accounts for a run of use-after-free and type-confusion entries, and there are separate entries for PL/Tcl, dblink, and the pg_dump, pg_restore, vacuumdb and reindexdb utilities.

Beyond security, the update fixes over 140 bugs, among them corruption bugs. The announcement describes fixes for GIN indexes that could lead to index corruption so that queries miss rows or return unrelated rows, for pg_trgm GiST indexes that could miss matching rows, and for incremental and base backups that could produce corrupt output. It also fixes a bug where a transaction that imported a snapshot taken on a standby could return wrong results, and a possible loss of rows during a table rewrite such as CLUSTER or VACUUM FULL when a row had been updated by a subtransaction that later aborted.

The release notes credit a wide group of reporters. For CVE-2026-6460 they thank, among others, the OpenAI Security Research Team, the Anthropic OSS program and Claude, together with Ada Logics. For CVE-2026-116306 they thank OpenAI Codex Security and Claude, among others. The notes do not break down how many of the 52 reports came from AI-assisted work, so we do not claim a figure.

Background

PostgreSQL ships minor releases on a regular schedule, and the project's versioning policy lists each major version's final release date. According to the policy page, PostgreSQL 14's final release is 12 November 2026, which is the day of this release, 15 runs until 11 November 2027, 16 until 9 November 2028, 17 until 8 November 2029 and 18 until 14 November 2030.

The fixes for CVE-2026-6460 and related bugs come from the same piece of work. The release notes describe a "voluminous set of patches" that adds defences against altering composite types concurrently with operations on data of those types. It introduces versioning logic so the server can detect composite values that do not match the row layout they are being read with, adds locking for cases such as ALTER TYPE on a composite type used in an uncommitted CREATE TABLE, and tightens when ALTER COLUMN TYPE is allowed if a function or SQL function body depends on the type. A new composite_type_mismatch server parameter can switch the checks off, but the notes say doing so carries security risks.

We have covered other maintenance-release waves recently, for example the Node.js security releases. The difference here is the scale: 52 CVEs in one PostgreSQL release.

The numbers

The chart groups the 52 CVEs by the CVSS v3.1 base score printed next to each in the announcement. The grouping is ours; the scores are the project's. The ComputingForGeeks write-up arrives at the same split (32 rated 8.8, two at 8.1, one at 8.0, three at 7.2, and 14 between 3.1 and 6.5).

8.0 to 8.835

Below 7.014

7.23

PostgreSQL November 2026 CVEs by CVSS v3.1 score band (CVEs)

	CVEs
8.0 to 8.8	35
Below 7.0	14
7.2	3

Source: PostgreSQL announcement of 12 November 2026 (grouping by audiotale.net)

ComputingForGeeks adds that most of the 8.8 entries share the vector AV:N/AC:L/PR:L/UI:N: network reachable, low complexity, low privileges, no user interaction. In its reading, for most of them the attacker is a role that can create a table, function or type and uses it to trigger a type confusion or use-after-free that ends in code execution as the operating-system account that runs PostgreSQL. It also says six need only a database user, so a read-only login without CREATE is enough. That analysis is the outlet's own reading of the CVE records, not a statement from the PostgreSQL project.

What it means

For database administrators, the most important point is the threat model. Many of the high-scoring bugs require an authenticated role, which makes them most relevant on shared servers, multi-tenant setups, analytics clusters where many people have logins, and anything that exposes SQL to semi-trusted users. A single-tenant database where only the application owner can log in is still affected, but an attacker first needs that role's credentials.

For teams that use extensions and procedural languages, the PL/Perl, PL/Tcl and dblink entries mean it is worth checking which databases have them installed, since the fix touches those components directly. The release notes' warning that C-language extensions may need a rebuild means managed-service users and package maintainers should expect follow-up releases of extensions.

For anyone on PostgreSQL 14, there is no further patch route. Upgrading to a supported major version is the only way to receive future security fixes. A minor update to 14.25 closes these holes and nothing after it will.

For backup and recovery, the incremental-backup advice is the item most likely to be missed. If your recovery plan relies on incrementals taken before this update, the project says not to trust them and to start again from a new full backup.

For managed database users, providers will roll the patch out on their own schedule. We have not checked any provider's timetable, so look at your provider's maintenance notes rather than assuming it has happened.

What we don't know yet

• Whether any of the 52 flaws are being exploited. The announcement does not say so and we found no report of exploitation.
• How quickly cloud providers and Linux distributions will ship the updated packages. We did not verify any provider's rollout.
• One search result suggested that PostgreSQL 15 also loses support with this release, but the project's own versioning page lists 15.20 as supported until 11 November 2027, and we follow the project.
• Which third-party extensions will need rebuilding or source changes because of the composite-type work.

What to watch next

• 19 November 2026: the planned general availability date for PostgreSQL 19, per the announcement.
• Extension releases: projects that ship C-language extensions may publish compatible builds.
• Distribution and cloud advisories: package updates from Debian, Ubuntu, Red Hat and the PGDG repositories, and managed-service maintenance windows.
• The next scheduled minor release: the project publishes dates on its versioning page.

Sources

• PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25, and 19 RC 2 Released (PostgreSQL Global Development Group, 12 November 2026)
• Release 18.7 notes (PostgreSQL documentation)
• PostgreSQL versioning policy (supported versions and final release dates)
• PostgreSQL 18.7 Security Update: 52 CVEs and Patch Steps (ComputingForGeeks, 12 November 2026)