The PostgreSQL Global Development Group shipped 18.7, 17.12, 16.16, 15.20 and 14.25 on November 12, 2026, together with the second release candidate of PostgreSQL 19. The update closes 52 security vulnerabilities and over 140 bugs. It is also the last release of PostgreSQL 14.
For a typical minor release you stop the server, swap binaries and start it again. This one adds post-update work if you use GIN indexes, pg_trgm, bpchar columns, incremental backups or partitioned tables.
- CVEs closed
- 52
- bugs fixed
- 140+
- final PostgreSQL 14 release
- 14.25
The security list
I counted the 52 entries on the announcement. Most carry a CVSS v3.1 score of 8.8 and a description ending in "executes arbitrary code". The list includes type confusion after ALTER ... SET DATA TYPE (CVE-2026-6460), use-after-free bugs in plperl and pltcl, heap buffer overflows in tsvector_delete() and ts_rank_cd(), and integer wraparounds in tuple sizing and the generation memory context.
A second group targets your tools instead of the server:
| CVE | Component | CVSS |
|---|---|---|
| CVE-2026-116314 | pg_restore runs code from an unvalidated non-plain archive | 8.8 |
| CVE-2026-116318 | pg_dump SQL injection through a not-null constraint name | 8.8 |
| CVE-2026-116330 | pg_dump tar restore.sql fails to block psql command injection | 8.8 |
| CVE-2026-116325 | reindexdb SQL injection through index name quoting | 8 |
| CVE-2026-116313 | vacuumdb --missing-stats-only runs code as the vacuumdb user | 7.2 |
| CVE-2026-16240 | pg_basebackup uses manifest content as a format string | 3.7 |
Those matter if you restore dumps from a source you don't control, or if a cron job runs vacuumdb or reindexdb as a superuser against databases that tenants own. Upgrade the client packages on your bastions and CI images along with the server.
Two more stand out for multi-tenant setups. CVE-2026-120145 lets logical replication write to subscriber system catalogs and execute code. CVE-2026-14661 lets dblink and subscriptions append to arbitrary files, scored 8.1.
Post-update steps
The bug fixes include several corruption issues. The announcement lists what to do once the new binaries run:
-- GIN indexes you suspect, and every pg_trgm GiST index (gist_trgm_ops)
REINDEX INDEX your_index_name;
-- tables that raised missing chunk number errors
REINDEX TABLE your_table_name;
-- NOT NULL NO INHERIT constraints on partitioned tables
SELECT conrelid::regclass, conname
FROM pg_constraint
WHERE contype = 'n' AND connoinherit
AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p');
Drop the constraints that query returns with ALTER TABLE ... DROP CONSTRAINT, or repair the ones you want with ALTER TABLE ... ALTER CONSTRAINT ... INHERIT. The repair fails if a partition already holds NULL in that column, and you'll need to clean the rows first.
Reindex B-tree indexes on columns declared as plain bpchar with no length. The release disables deduplication for them because index-only scans could return wrong results. char(n) columns are fine.
If you take incremental backups, take a new full backup after you upgrade and chain future incrementals from it. The project fixed several bugs that could produce corrupt incremental backups.
The planner also got a rework of join removal, which the announcement calls a significant change for an update release. Watch query plans on your heaviest reports after the upgrade.
PostgreSQL 14 and 19
PostgreSQL 14 will receive no more security or bug fixes after 14.25. Today's 52 CVEs are the last batch it gets.
PostgreSQL 19 RC 2 includes the same fixes. The project plans general availability for November 19, 2026. If you tested 19 and created expression indexes, generated columns or partition keys with JSON_ARRAY() or JSON_OBJECT() over arrays, composites or ranges, drop or redefine them: RC 2 reverts that feature, and pg_upgrade and pg_restore will fail to recreate those objects.
This week
- Upgrade servers and client tools to 18.7, 17.12, 16.16 or 15.20. Restart each server after the package swap.
- Run the reindex steps that match your schema, and run the partitioned-table query above.
- Take a fresh full backup if you use incremental backups.
- Put a PostgreSQL 14 major upgrade on the calendar. You can target 18 now or wait for the planned PostgreSQL 19 release on November 19.
Volodymyr Chornous