PostgreSQL ships its biggest security release of the year
PostgreSQL just shipped the largest security update of its year. On November 12 the PostgreSQL Global Development Group rolled out fixes for 52 vulnerabilities across five supported versions, then folded in a second release candidate for the not-yet-final PostgreSQL 19. Almost all of those flaws carry a Critical rating of 8.8 and describe a way for an attacker with modest privileges to run arbitrary code as the OS user behind the database server. That is a full host compromise, not a browse-and-leave situation.
It is a coordinated drop across every maintained train: 18.7, 17.12, 16.16, 15.20, and 14.25, all published the same day. A few mirror-tracking services first recorded them on or before November 9, though the official notes are dated the 12th. Alongside the security holes, the release notes catalog more than 140 additional bug fixes covering everything from wrong query results to crash-safety around checkpoints. Every CVE in the set affects versions before this update, so if you skipped the last round you have some catching up to do.
What the 52 CVEs add up to
The numbers dominate the conversation. Nearly all 52 are 8.8, which lands hard in the Critical band. The defect class of the cycle is type confusion married to use-after-free and heap buffer overflows. PostgreSQL misreads an in-memory structure, an attacker pushes an out-of-bounds write, and code execution follows shortly after. The fix basically shuts those misinterpretations shut.
You find these paths spread everywhere this time. Several cluster in the PL/Perl and PL/Tcl procedural languages, where re-entrant calls reopen reference bugs. Others ride the backup and restore tooling that DBAs run against their own machines. CVE-2026-116314 lets pg_restore execute arbitrary code off a missing-non-plain-archive validation gap, and CVE-2026-116318 patches a related SQL-injection hole in pg_dump's not-null handling. Lower down the scale, CVE-2026-16240 is a format-string slip in pg_basebackup, but it needs some oddly named files already living in your data directory to trip.
Here is the part people usually skip. The PostgreSQL Global Development Group says there were no known reports of exploitation in the wild at the time of release. That is not a reason to relax. It just means these are theoretical until someone writes the proof, and experience says the proof tends to arrive eventually.
The count of fixed vulnerabilities has climbed sharply year over year, from 4 in 2025 to 39 in 2026, and a decent share of the new findings now comes from automated tooling and bug-bounty programs rather than just human auditors. The release notes even credit teams from the "Anthropic OSS program" and the "OpenAI Security Research Team" alongside long-time core contributors. So the honest question is whether PostgreSQL is getting riskier or we are just getting better at finding the flaws. Probably both.
The versioning picture
This release is also the final one for PostgreSQL 14. With 14.25, that version goes end of life and stops receiving fixes of any kind.
The project supports a major version for five years, then publishes one last minor release before retiring it. PostgreSQL 14 first shipped on September 30, 2021, so this is where that clock runs out. The PostgreSQL Global Development Group strongly recommends anyone still on 14 in production move to a supported train, and the reasoning is stark: the vulnerabilities fixed here stay wide open forever on an unsupported version.
| Version | Current minor | Supported | First released | 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 | No, EOL today | September 30, 2021 | November 12, 2026 |
On the other end of the timeline sits PostgreSQL 19. RC 2 landed the same day as the stable drop, and the release team says it will be "mostly identical" to the final 19.0 going general availability on November 19, one week away. In practical terms RC 2 is essentially the finished product wearing a pre-release name tag. PostgreSQL officially files version-19 docs under "unsupported versions," but that is a cosmetic quirk of its process. The team simply reserves the word "final" until the GA date, the same way tooling sometimes flags stable minors as pre-releases just because of a tag suffix.
If you were tempted to try 19 early, the RC is fine for staging and testing, but treat production upgrades as a pg_upgrade or dump-and-restore job. Keep an eye on the default changes too: JIT is off by default now, lz4 has become the default TOAST compression, and max_locks_per_transaction doubled from 64 to 128, which effectively halves lock capacity in older deployments unless you adjust settings. Still worth taking seriously before you flip any of those switches.
Before you run the update
Unlike many minor releases, this one asks for a few manual follow-ups on affected systems. The binaries are cumulative, so stopping PostgreSQL and swapping them in works without a full pg_upgrade. But several fixes touch silent data corruption that a plain upgrade won't repair on its own.
If you use GIN or pg_trgm GiST indexes, reindex them. Same for any table throwing missing chunk number errors, which also points at a TOAST index. There is also a reworked join-removal step in the planner plus fixes for B-tree de-duplication on char(n) columns, both worth a reindex if you hit the affected patterns. The PostgreSQL Global Development Group recommends a fresh full backup before leaning on incremental backups again, since some incremental-backup and base-backup fixes landed in this set too.
To find and clean up a leftover partition constraint, the project points to a query against pg_constraint for NOT NULL NO INHERIT entries, then either drops them or repairs them with ALTER TABLE ... ALTER CONSTRAINT ... INHERIT.
Head here for the downloads, the full release notes, security advisories, and the EOL schedule.
