PostgreSQL fixes 52 flaws and ends support for version 14

PostgreSQL fixes 52 flaws and ends support for version 14

12 November 2026: The PostgreSQL Global Development Group has released 18.7, 17.12, 16.16, 15.20 and 14.25, which fix 52 security vulnerabilities and more than 140 bugs, the largest number of the 52 rated 8.8 under CVSS 3.1 because an authenticated user can turn them into code execution on the server. None is reported as exploited. Version 14 gets nothing after this: in the project's words, "this is the final release of PostgreSQL 14".

Not yet independently verified. The scores and descriptions are the PostgreSQL project's own, from its release announcement; we have not read each CVE page for its affected versions, and no exploitation has been reported. We will update this when it can be confirmed, and remove this note.

The flaws that matter most

Most of the high scores need a database login, which is why so many share 8.8: the attacker is a user with ordinary privileges who reaches arbitrary code through type confusion, a use-after-free or an integer wraparound. A few stand out for teams that move data between servers.

• CVE-2026-116314 (8.8): pg_restore runs arbitrary code because non-plain archives are not validated, so restoring a dump from an untrusted source is a risk.
• CVE-2026-116330 (8.8): a pg_dump tar archive's restore.sql does not block psql command injection.
• CVE-2026-116318 (8.8): a not-null constraint name lets pg_dump emit SQL injection.
• CVE-2026-120145 (8.8): logical replication can write to a subscriber's system catalogs and run code there.
• CVE-2026-14661 (8.1): dblink and subscriptions can append to arbitrary files.
• CVE-2026-116313 (7.2): vacuumdb with --missing-stats-only lets a database owner run code as the vacuumdb user.
• CVE-2026-116322 (5.3): a cancel request sent before authentication can leak a spinlock.

Seven of the code-execution flaws sit in PL/Perl and one in PL/Tcl, so servers with those languages installed carry more of the exposure.

Steps after the binaries are swapped

A minor update needs no dump and reload and no pg_upgrade, but the announcement lists work to do afterwards. Teams should reindex any GIN index they suspect is corrupted, every GiST index that uses the gist_trgm_ops operator class of pg_trgm, and B-tree indexes on bpchar columns declared without a length (char(n) columns are not affected). A table that throws "missing chunk number" errors needs REINDEX TABLE, which also rebuilds its TOAST table. Anyone using incremental backups should take a new full backup after updating and base later increments on it. Partitioned tables should be checked for invalid NOT NULL NO INHERIT constraints with the query the project gives. Servers that skipped earlier minor releases may owe the steps listed in those releases too.

Version 14 is out of support

A production database still on PostgreSQL 14 has no further security fixes from today, and the project suggests planning an upgrade to a supported version. Managed database services set their own schedules for retiring a major version, so the date by which a hosted 14 instance is forced forward is the provider's to state, not the project's.

PostgreSQL 19 a week away

The same announcement brought 19 RC 2 and plans general availability for 19 November 2026, unless an issue forces a delay. RC 2 reverts a change that allowed JSON_ARRAY() and JSON_OBJECT() over arrays, composite and range types in expression indexes, generated columns and partition keys. Anyone who built such objects while testing 19 must drop or redefine them before upgrading, because pg_dump, pg_restore and pg_upgrade will fail to recreate them.

Our catalogue lists six database monitoring products and 27 NoSQL databases.

Sources

• PostgreSQL: PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25, and 19 RC 2 Released, 12 November 2026
• Help Net Security: PostgreSQL security update, November 2026, 13 November 2026