PostgreSQL November 2026 Release: 52 Security Fixes and Update Checks

PostgreSQL November 2026 security release updates supported branches to 18.7, 17.12, 16.16, 15.20 and 14.25. The PostgreSQL Global Development Group says its November 12 release closes 52 security vulnerabilities and fixes over 140 bugs. PostgreSQL 19 RC 2 also includes applicable fixes, but it remains a release candidate.

Administrators should plan the minor update, then check whether their deployments need the extra repair steps in the official release announcement. The security items and the data-integrity repairs call for different follow-up work. The release also marks the end of PostgreSQL 14 support.

Which versions are covered by the PostgreSQL November 2026 security release?

The five supported production branches have separate fixed builds. Minor releases are cumulative, so the project says administrators can stop PostgreSQL and update the binaries without a dump, reload or pg_upgrade. Teams that skipped earlier updates should review the older release notes for additional steps.

PostgreSQL 14.25 is the branch’s last release, and PostgreSQL 14 is now end-of-life. A production deployment on 14 therefore needs a major-version migration plan after this final minor update. PostgreSQL 19 RC 2 is for release-candidate testing and requires a major upgrade strategy from older versions.

Which security issues change the patch priority?

CVE-2026-6460 is a type-confusion flaw that can let an object creator run code as the database server’s operating-system user. PostgreSQL attributes the flaw to inadequate tracking of typed values, allowing stale values in system entries and variables. Its published CVSS 3.1 score is 8.8; the opened PostgreSQL and NVD records provide no CVSS 4.0 score.

The release also lists CVE-2026-18447 and CVE-2026-116304 among code-execution flaws scored 8.8 in CVSS 3.1. Those are separate entries, so defenders should review the vendor’s individual advisory for each before assigning exposure. For CVE-2026-6460, start with who can create database objects and which server instances run an older branch build.

A reachable database endpoint deserves early inventory attention, alongside its authorization model. A vulnerability intelligence platform can support patch prioritization while database owners confirm installed versions and privileges. That is a prioritization step, not evidence that every listed flaw is remotely exploitable without access.

What else is in the security list?

The announcement lists permission and row-boundary issues alongside code execution. CVE-2026-16237 concerns an updatable view’s WHERE condition, while CVE-2026-120154 concerns row security with INSERT … ON CONFLICT. Teams relying on views or row security should include those paths in post-update regression checks.

Maintenance utilities have their own entries. The project says CVE-2026-116314 concerns pg_restore archive validation, and CVE-2026-116318 concerns a pg_dump constraint name. CVE-2026-116313 affects vacuumdb when a database owner can use its missing-statistics option. Apply the binaries and review who can run backup, restore and maintenance tools.

Which bug fixes need work after updating?

The release warns that several GIN index issues could cause missed or unrelated query rows. Suspected affected GIN indexes should be reindexed after the update. It also directs pg_trgm users to reindex GiST indexes using gist_trgm_ops and notes a separate TOAST reindex case after missing-chunk errors.

Incremental backups need a fresh full-backup baseline after patching, according to the project. The release also describes a snapshot-import problem that could corrupt a parallel dump and standby data. Teams should validate backup and restore results, rather than treating a successful binary update as a complete data-integrity check.

Other corrections cover partitioned-table constraints and B-tree indexes on lengthless bpchar columns. The vendor provides a check for affected NOT NULL NO INHERIT constraints and advises reindexing the specified B-tree indexes. Use the release’s detailed Updating section to match each repair to features actually deployed.

How should teams run this update?

First, map installed major and minor versions to the fixed-release table. Then prioritize older builds where object-creation rights, maintenance utilities or sensitive data paths increase the impact of the listed issues. A vulnerability prioritization process can keep that scope tied to actual deployment facts.

• Inventory PostgreSQL branchesRecord every server and its installed minor version.
• Apply the fixed releaseFollow the deployment’s normal stop and binary-update procedure.
• Check affected featuresReview object creators, maintenance utilities, indexes and backups.
• Complete repair stepsReindex or rebuild backups where the official Updating section requires it.

From August 14 through November 12, 2026, Brandefense Blackhole counted two dark-chat posts matching CVE-2026-6460. The unit is matching posts, not incidents, and the count does not establish exploitation. Keep the patch decision grounded in the official advisory and your own exposure review.

Finally, record the installed version after restart and test critical queries, replicas and restore procedures. Use the patch management workflow to track the binary change separately from follow-up reindexing or backup work. That distinction makes the remaining operational steps visible to the database owner.