The PostgreSQL project released updates on November 12 that fix 52 security vulnerabilities and more than 140 other bugs across five supported branches, and it declared PostgreSQL 14.25 the final release of version 14. The affected releases are 18.7, 17.12, 16.16, 15.20 and 14.25.
A Record Batch of 52 Server and Client Flaws
Thirty-two of the vulnerabilities score CVSS 8.8, the highest rating in the batch. The lowest score is 3.1. One outlet said the batch nearly doubles the previous record of 28 fixes, set in August.
Most of the serious flaws are memory errors or type-confusion bugs that can lead to code execution as the operating system account running PostgreSQL. An attacker needs to be authenticated or to hold the ability to create database objects. The affected areas include PL/Perl, PL/Tcl, ts_rank_cd(), parallel query, logical replication, dblink and statistics import.
Named CVEs in the Server Components
Examples include CVE-2026-6460, CVE-2026-120141, CVE-2026-120139 and CVE-2026-120149. CVE-2026-120145 allows code to run from publisher to subscriber in logical replication, which makes the replication path itself a route for an attack.
pg_dump, pg_restore and Other Client Tool Bugs
The client tools carry their own flaws. pg_dump has an SQL injection issue involving not-null constraint names. CVE-2026-116314 lets a tar restore in pg_restore trigger psql injection. Flaws also affect reindexdb and vacuumdb.
PostgreSQL 14.25 Is the Final Version 14 Release
PostgreSQL 14.25 is the last release in the 14 line, so organizations still running it will not receive further security fixes. The project also shipped PostgreSQL 19 Release Candidate 2, with general availability planned for November 19.
Shared and hosted database environments face the sharpest risk from the code-execution bugs. A tenant who can create objects or run queries could escape to the host account, which turns a low-privilege database user into a threat to every other tenant on the same server. The project has no confirmed exploitation or public proof of concept for the flaws.
Upgrade Steps Beyond the Binary Swap
Updating the server and client binaries is the first step, but the project lists follow-up work. Administrators need to reindex GIN indexes, pg_trgm GiST indexes and bpchar B-tree indexes. Users of incremental backup should take a fresh full backup after upgrading.
Why the Version 14 Cutoff Raises the Stakes
The end of support for 14 coincides with the largest security batch the project has issued. Teams that postpone moves off version 14 will carry the 52 flaws fixed here with no route to patch future ones, and any new vulnerabilities in the branch will go unfixed.
The scale of the release is a prompt for patch planning rather than a cause for alarm: the code-execution flaws require authenticated access or object-creation rights, and the project reports no attacks. Still, 32 of 52 fixes at the top severity rating means database administrators should schedule the upgrade and the index rebuilds together, since skipping the reindex step leaves some of the fixes incomplete for affected index types.
Which Deployments Face the Most Exposure
Hosted and shared database setups face the highest consequence because the code-execution flaws require only an authenticated user or one able to create objects. In a multi-tenant arrangement, those are ordinary customer privileges, so a flaw that runs code as the PostgreSQL operating system account becomes a way across the boundary between tenants and the host.
Client Tools and Replication as Overlooked Paths
The client-tool flaws in pg_dump, pg_restore, reindexdb and vacuumdb matter for backup and maintenance jobs that run with elevated access against untrusted databases. The logical replication flaw in CVE-2026-120145 adds a path in which code runs from the publisher to the subscriber, so a compromised publishing server can become a way into the servers that subscribe to it.
