PostgreSQL says 18.7 fixes 52 CVEs, 32 of them rated 8.8, and 14.25 is the last PostgreSQL 14 release

52 CVEs in the table, 32 of them scored 8.8 (derived)

The PostgreSQL Global Development Group's announcement of 12 November 2026 says the update "fixes 52 security vulnerabilities". Counting the table beneath that sentence gives 52 CVE rows, and 32 of them print a score of 8.8 (derived: 32 of 52, 61.5 per cent). The highest score printed is 8.8, the lowest is 3.1, none reaches 9.0, and the median is 8.8, because the 26th and 27th of the 52 scores in order are both 8.8 (derived). The releases are PostgreSQL 18.7, 17.12, 16.16, 15.20 and 14.25, plus a second release candidate of PostgreSQL 19. The announcement also says "This is the final release of PostgreSQL 14".

What that count does not establish. It counts flaws fixed, not attacks. The announcement and the 52 project CVE pages say nothing about exploitation, publish no proof of concept and print no workaround (each searched in the saved pages). The CVE.org records add two workarounds, for CVE-2026-14661 and CVE-2026-116330, and, on 36 of the 52, an entry from CISA's enrichment programme (CISA-ADP) that prints Exploitation: none, time stamped 12 November (derived; the other 16 records carried no such entry when read). The pages do not say whether managed services such as Amazon RDS, Google Cloud SQL or Azure Database for PostgreSQL have applied the update; the provider's own notice is the place to look. The scores are the project's own, and no page here compares this release with an earlier one, so "52 in one release" is a figure without a baseline.

PostgreSQL is a community project with no product to sell on this page; its announcements list vendor neutral fixes. Companies that host PostgreSQL as a managed service sell the service, and they are not parties at fault.

The table counted: scores, the 8.8 block, and a version label that differs

The announcement lists each CVE with a one line title and a score labelled "CVSS v3.1". There are ten different printed scores. The 8.8 block is far the largest: 32 rows. The next score down, 8.1, appears twice. The project's per CVE pages add what the announcement leaves out: a vector, a component and the branches fixed.

The 10 counts add to 52 (32, 2, 1, 3, 1, 3, 1, 7, 1, 1). A version label differs. The announcement says CVSS v3.1. Each project CVE page heads its score "CVSS 3.0" and prints a vector with no version prefix; each CVE.org record prints the same vector with the prefix CVSS:3.1 and the same score. The vectors and scores agree on all 52, and this site recomputed every score from its vector with the public CVSS 3 base formula and got the printed value each time (derived). So the label disagrees and the numbers do not.

Zoom

By component: 36 in the server, 7 in procedural languages, 6 in client tools, 3 in contrib

The announcement does not group the 52. Each project CVE page, and the matching CVE.org record, carries a component field. Its values are core server for 43, client for 6 and contrib module for 3 (all 52 read). The seven entries for the procedural languages PL/Perl (5), PL/Tcl (1) and PL/pgSQL (1) are filed under core server, so this site splits them out by the language named in the title. The result is the table below (derived).

Other groupings by title (derived): two entries concern statistics, one on import and one on extended statistics; two mention logical replication or subscriptions, CVE-2026-120145 and CVE-2026-14661; two are in dblink. Client tools are the practical catch. Six CVEs are in programs that run wherever an administrator, a script or a backup job runs them: pg_dump (two), pg_restore, pg_basebackup, vacuumdb and reindexdb. The announcement's Updating section speaks of stopping PostgreSQL and updating its binaries and never separates server from client, so it is this site's inference, not the project's statement, that a patched server does not patch a pg_dump on another host. Three of the six reach all five branches, one reaches 18 and 17, and two exist only in 18 (derived from the CVE pages).

A client library case. CVE-2026-14661 is filed under contrib module (dblink and subscriptions), yet its page says versions before 18 "are also affected if libpq version 18 or later is installed and in use by the server". That ties the exposure of an older server to the version of a client library on the same host, not only to the server's own version. The announcement does not mention it.

Memory errors and type confusion: the page does not classify, CVE.org does

The announcement titles often name a mechanism, such as type confusion, use after free or integer wraparound, but it carries no weakness classification. The CVE.org records, published by the project as the numbering authority, do: each carries a CWE tag. Counting those (derived from all 52 records): 31 of the 52 records carry at least one of five memory or type tags, namely CWE-843 type confusion on 14, CWE-416 use after free on 11, CWE-122 heap based buffer overflow on 3, CWE-126 buffer over read on 2 and CWE-190 integer overflow or wraparound on 2. That is 32 tags on 31 records, because CVE-2026-116304 carries both CWE-416 and CWE-843. Of the 32 scored 8.8, 26 carry one of those tags (derived); the other six are CVE-2026-116314, 116316, 116318, 116326, 116330 and 120145.

Titles and tags count differently. Counting title words, as the announcement words them, gives 10 titles with "type confusion" and 10 with "use-after-free". The tags give 14 and 11. The difference is in wording, not in the facts: for example CVE-2026-116306 is titled "Composite-type change during field assignment executes arbitrary code" and is tagged CWE-843. Twenty-five titles say "executes arbitrary code" and two say "may execute arbitrary code" (derived by phrase search). The page does not say that any of them has been executed by anyone.

Who can reach them: one CVE needs no account, and the word network does not mean the internet

All 52 vectors print AV:N, attack vector network, including the six in client tools. That letter says the vulnerable component is bound to the network stack; it does not say a server is open to the internet or that an attacker can reach a pg_dump run on a laptop. The privileges letter is the better guide to who can reach each flaw (derived from the 52 vectors): PR:L, a low privilege account, on 44; PR:H, a high privilege account, on 3; PR:N, none, on 5. The CVE descriptions name the attacker in words: an object creator, a database user, a database owner, a user with database level CREATE privilege, a compromised publisher, a compromised origin server, a provider of a crafted archive.

Only one of the 52 is described as reachable by an unauthenticated network client. CVE-2026-116322, scored 5.3 and in 18 only, "allows an unauthenticated network client to trigger a server restart", through a pre-authentication cancel request. The other four with PR:N are CVE-2026-16240 (a server that has already been compromised, 3.7), 116314 (a crafted archive passed to pg_restore, 8.8), 116330 (a compromised origin server, with code running as the account that runs psql, 8.8) and 120145 (a compromised publisher, 8.8, and the page says "Only subscriptions owned by a superuser are vulnerable"). Three of those four set UI:R, so a person or job has to run the tool or subscription. Of the 32 scored 8.8, 29 are PR:L with no user interaction and 3 are PR:N with user interaction (derived).

A label standing in for a control. "Executes arbitrary code" is the phrase that does the work in 25 titles, and the 8.8 beside it looks like the same sentence in numbers. The vector says something narrower: for 29 of the 32 the attacker needs an account that can create objects or run queries, and the page's own words call that attacker an object creator or a database user. Where untrusted people hold such accounts, that is a serious gap; on a database with only trusted application roles it is a smaller one. The scores do not say which database you run, and the project does not say either.

The records state a condition for 41 of the 52 (derived; the other 11 have none). For the five PL/Perl entries and the PL/Tcl entry, the condition is that the attacker has permission to run CREATE EXTENSION for that language, or another user previously did, and has permission to create objects. For the two dblink entries, a superuser must have issued CREATE EXTENSION dblink first (and, for CVE-2026-14661, must have granted pg_create_subscription to non superuser roles). Read that way, a database that never installed PL/Perl, PL/Tcl or dblink is outside those eight entries; the pages do not say how many are. CISA-ADP's entry on CVE-2026-116322 is the only one of the 36 that prints Automatable: yes.

Who the CVE records thank: organisations named in 23 of 52

The announcement credits nobody. The CVE.org records do, with one line each, always of the form "The PostgreSQL project thanks ... for reporting this problem" (all 52 read). Most names are individuals, whom this briefing does not name. Some are organisations or programs, and 23 of the 52 records name at least one (derived). The credit lines do not say how any flaw was found, whether a tool was used or what the organisation did.

The 16 records for the Anthropic OSS program and the four that name Claude do not overlap, and the Ada Logics lines are the same four as the Claude lines (derived). Anthropic and OpenAI both sell AI products, and each is named here only because of what these credit lines say. The records do not say that either company's product found a flaw, what any named program is, or why the names appear in the form they do. Take the table as a statement of who the project thanked, not of how bugs were found.

What each fix needs from an administrator: the project's list, and one reading of this site's

The announcement's Updating section is short. It says "All PostgreSQL update releases are cumulative", and that users are not required to dump and reload or use pg_upgrade; "you may simply stop PostgreSQL and update its binaries". Then it lists the exceptions, each of which needs a person to do something.

Zoom

What is not on the list. The announcement gives no step for the 52 CVEs beyond installing the update, no command to find out which CVE applies to a given host, and no deadline for 14 users. The six client tool CVEs are in the CVE pages, not the announcement, and the two workarounds are in the CVE.org records only. The announcement says "Users who have skipped one or more update releases may need to run additional post-update steps", which, with 52 CVEs and more than 140 bugs in one release, makes the previous release notes part of the job and not a footnote.

The end of PostgreSQL 14: 5 years and 43 days, and 40 of the 52 fixes reach it

The announcement says "PostgreSQL 14 is now end-of-life and will no longer receive security and bug fixes" and that anyone running it in production should "make plans to upgrade to a newer, supported version of PostgreSQL". It names no target version, no date and no steps beyond pointing to the versioning policy. That policy page says the project "supports a major version for 5 years after its initial release", and its release table lists 14.25 with a first release of 30 September 2021 and a final release of 12 November 2026. That is 5 years and 43 days (derived: 30 September 2026 plus 43 days is 12 November 2026), or 1,869 days. The same table gives the end of each remaining branch: 15 on 11 November 2027, 16 on 9 November 2028, 17 on 8 November 2029 and 18 on 14 November 2030.

What 14.25 carries. The CVE pages list PostgreSQL 14 among the fixed branches for 40 of the 52 CVEs (derived from the Fixed In table on each page), including 27 of the 32 scored 8.8. The other 12 are limited to newer branches: 5 to 18 only, 4 to 18 and 17, two to 18, 17 and 16, and one to 18 down to 15. Those 40 are the last security fixes 14 will receive from the project, and anything found in 14 after today is, on the page's own words, outside support. The announcement does not say what happens to a flaw reported against 14 later.

Two sources differ on the date. When read at about 07:12 UTC on 13 November 2026, the versioning policy page still printed Yes in its Supported column for 14, with the final release date 12 November 2026 beside it. The announcement says 14 is now end of life. Both agree on the date; the table label had not changed by the time of reading. Branch 13 shows No, with a final release on 13 November 2025, exactly one year before this reading (derived), so a 13 or older host has been outside support for at least that long.

PostgreSQL 19 RC 2: a reverted change, and 19 November as the planned date

The page says that as a release candidate, "PostgreSQL 19 RC 2 will be mostly identical to the initial release of PostgreSQL 19", though more fixes may be applied before release. It says "PostgreSQL 19 should be made generally available on November 19, 2026", 7 days after the announcement (derived), unless a problem forces a delay or a further candidate. RC 2 also includes the fixes of this update that apply to 19.

The reversion. The first change the page lists since RC 1 reverts one that had allowed JSON_ARRAY() and JSON_OBJECT() over arrays, composite types and range types in expression indexes, generated columns and partition keys, because those indexes "could become out-of-date". Anyone who tested 19 needs to act: "you need to drop or redefine them before upgrading, as pg_dump / pg_restore and pg_upgrade will fail to recreate them". In practice that means a list of expression indexes, generated columns and partition keys that use JSON_ARRAY() or JSON_OBJECT() over arrays, composite types or range types, to be dropped or redefined before a pg_upgrade or a dump and restore. The page prints no query to find them. The announcement also says that pg_upgrade users with indexes for full text search, pg_trgm or fuzzystrmatch should read the release notes' migration section, which this briefing did not read.

What PostgreSQL states, and what it does not

Where the sources differ

A press summary of the release was not read: every figure here comes from the project's pages and records. It is easy to assume the announcement credits the reporters of each CVE; it credits nobody, and the credit lines are in the CVE.org records.

What to do, in order

Technical details

The announcement prints no indicators, no detection queries and no exploit detail, and this briefing adds none. What it prints is a list of fixed versions, three kinds of SQL for administrators, and a table of 52 CVEs. They are reproduced below, each with a sentence on what an administrator does with it. The CVE pages and CVE.org records add the vectors, components and branches.

Fixed versions and support dates. These are the release name from the announcement and the versioning policy table. An administrator compares the running server and client versions with the first column of each line and the fixed number.

PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25, and 19 RC 2 Released!

Version Current minor Supported First Release Final Release
18 18.7 Yes September 25, 2025 November 14, 2030
17 17.12 Yes September 26, 2024 November 8, 2029
16 16.16 Yes September 14, 2023 November 9, 2028
15 15.20 Yes October 13, 2022 November 11, 2027
14 14.25 Yes September 30, 2021 November 12, 2026
13 13.23 No September 24, 2020 November 13, 2025

Reindex statements. The announcement prints these two as examples. An administrator replaces the name with the suspect index, or with the table that returns missing chunk number errors, and runs it in a maintenance window.

REINDEX INDEX your_index_name;
REINDEX TABLE your_table_name;

Finding NOT NULL NO INHERIT constraints on partitioned tables. The query is the announcement's. An administrator runs it in each database that uses partitioned tables; any row it returns is a constraint to drop or repair with the two statements printed after it. The repair fails if a partition holds NULLs.

SELECT conrelid::regclass, conname
FROM pg_constraint
WHERE contype = 'n' AND connoinherit
  AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p');

ALTER TABLE ... DROP CONSTRAINT ...
ALTER TABLE ... ALTER CONSTRAINT ... INHERIT

What a score means, for the 8.8 block. The first CVE in the table, with the project's page and the CVE.org record side by side. The record's configurations field states the condition for the attacker. A defender reads the privilege letter and the configurations line to see whether the accounts that can create objects on their database are trusted.

CVE-2026-6460, project CVE page:
CVSS 3.0 Overall Score 8.8   Component core server
Vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE-2026-6460, CVE.org record (assigner PostgreSQL):
cvssV3_1.vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
cvssV3_1.baseScore: 8.8
problemTypes: CWE-843
configurations: attacker has permission to create objects (temporary objects or non-temporary objects in at least one schema)

Reading, this site's: AV:N network, PR:L low privileges, UI:N no user interaction, C:H I:H A:H high on all three.

The one entry that needs no account. CVE-2026-116322 is the only one of the 52 whose description names an unauthenticated network client. It affects version 18 only. An administrator on 17 or earlier has nothing to do for this one; one on 18 updates to 18.7.

CVE-2026-116322, project CVE page, description and versions as printed:
Improper locking in PostgreSQL startup processing allows an unauthenticated network client to trigger a server restart, via arranging for authentication_timeout to arrive while it holds a spinlock during cancel handling.
Within major version 18, minor versions before PostgreSQL 18.7 are affected. Versions before PostgreSQL 18 are unaffected.
CVSS 3.0 Overall Score 5.3   Component core server   Vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

The client library condition. The page for CVE-2026-14661 ties older servers to the version of libpq on the host. An administrator checks which libpq version the server process loads, not only the server version.

CVE-2026-14661, project CVE page, as printed:
Within major version 18, minor versions before PostgreSQL 18.7 are affected. Versions before PostgreSQL 18 are also affected if libpq version 18 or later is installed and in use by the server.

Workarounds in the CVE.org records. Two records print a workaround, and the announcement and CVE pages print none. An administrator who cannot update at once can consider these two, after testing them, and removes the permission changes when the fix is applied. They are the PostgreSQL project's text, copied exactly.

CVE-2026-14661, CVE.org record, workarounds field:
Revoke public EXECUTE permission on dblink functions
Revoke pg_create_subscription from any roles that do not already have pg_write_server_files privileges

CVE-2026-116330, CVE.org record, workarounds field:
use pg_restore instead of running restore.sql

What CISA's entry says. On 36 of the 52 records a second container from CISA-ADP prints an SSVC assessment. All 36 print Exploitation: none; this is the entry for the one record marked Automatable: yes. It is CISA's field, not the project's, it is time stamped 12 November, and a defender rereads the record before relying on it.

CVE-2026-116322, CVE.org record, CISA-ADP container (role CISA Coordinator, SSVC version 2.0.3, timestamp 2026-11-12T21:21:48.203823Z):
Exploitation: none
Automatable: yes
Technical Impact: partial

The question the page leaves open

Forty of the 52 fixes reach PostgreSQL 14 today, and no further release will carry any after them. Which hosts in your estate still run 14, who owns the date they leave, and has the client side, the pg_dump on the backup host, been updated alongside the server?

Key facts