PostgreSQL ships 28 security fixes in one go and puts version 14 on the clock
On August 13, 2026, the PostgreSQL project released 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3, fixing 28 security vulnerabilities — a record — including a dozen memory bugs exploitable for code execution. Apply the minor release now, and if you are still on version 14, plan the major upgrade before November 12, 2026.
August 13, 2026. The PostgreSQL project ships six releases at once: 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3. They close 28 security vulnerabilities and more than 110 bugs. On November 12, 2026, version 14 stops receiving fixes.
This is not a routine patch cycle. Twenty-eight CVEs in a single batch of minor releases is the largest in the project’s history — the previous record was eleven, set just three months earlier, in May 2026. For a DBA or SRE running PostgreSQL in production, that number is not trivia: it says something about the maturity of the attack surface, and about how fast you need to move.
A record 28 CVEs, a dozen of them exploitable memory bugs
The headline is the count, but the signal is the type of flaw. Of the 28 CVEs, roughly half carry a CVSS 8.8 score with the same pattern: “executes arbitrary code”, reachable by any authenticated role, no administrator privilege required (PR:L in the CVSS vector). In plain terms: any user holding an application account can, on a vulnerable instance, make the server run code.
The mechanism is almost always the same, and it is unsafe memory. CVE-2026-14664 (heap buffer overflow in the regular-expression engine), CVE-2026-14669 (to_char), CVE-2026-14676 (pg_stat_statements), CVE-2026-14670 (plperl tied objects), CVE-2026-14671 (type confusion in the refint plan cache), CVE-2026-16238, CVE-2026-16239, CVE-2026-19385 (pg_dump): every one of them is a buffer overflow or a type confusion that turns a low-privilege role into code execution. The structural lesson is blunt — PostgreSQL is written in C, and it keeps paying the price of unsafe memory. One of these flaws is enough to escalate an application account into a full compromise. The practical takeaway is that the attack surface is your application layer: every service account that connects to the database is a potential entry point for these flaws, so the patch is not optional — it is the difference between a contained app and a compromised host.
There are quieter traps too. CVE-2026-14663 makes pgcrypto silently encrypt to cleartext when asked for a cipher disabled in OpenSSL: the encryption appears to succeed, but the output is readable. CVE-2026-14672 exposes a user-existence oracle through scram_iterations. CVE-2026-6464 makes an early COPY FROM STDIN failure in psql process the remaining data lines as psql commands. None of these three needs any privilege: they hit the client or the protocol, not just the server.
This cadence is not an accident. By HeroDevs’ count, the project has already published 44 CVEs since the start of 2026 — more than in the whole of the previous year. The pressure comes from two directions: more systematic auditing (fuzzing, assisted review) surfacing more memory flaws, and an attack surface that grows with every extension and feature. For the team operating the database, the translation is simple: security patch cadence stops being a quarterly event and becomes continuous.
Version 14 changes the calculus: one more release, then nothing
The second message in this batch is a date. PostgreSQL 14 stops receiving fixes on November 12, 2026. The release that just shipped (14.24) is the second-to-last minor for the branch — the project’s quarterly cadence leaves exactly one more update before the five-year support window closes.
Who does this hit? PostgreSQL 14 is still widely deployed: released in September 2021, it carried a large share of the 2022–2024 migrations. If your estate still runs 14, you are far from alone — but you are now on a clock. The next quarterly patch batch, in November 2026, will be the last to cover 14. After that, a critical CVE published against 14 stays unpatched.
For teams still on 14, the practical path is well-trodden: run pg_upgrade --check against a restored copy, catalog every extension and its major-version compatibility, and rehearse the cutover window in advance. The quarterly cadence means the final 14 release lands in November — every month spent planning now is a month you will not have to improvise later.
That is exactly the window attackers watch. An end-of-life PostgreSQL concentrates two risks: known flaws left unfixed from November onward, and no simple upgrade path — the major migration (14 → 15, 16, 17 or 18) is not an apt upgrade, it is a project.
Three post-upgrade steps you cannot skip
The official announcement flags three items that may require manual action after applying the minor. They are easy to miss if you only read the title, and two of them concern very common extensions.
Parallel GIN index builds, the btree_gist extension and the ltree extension each have behavior affected by this batch. The practical consequence: if you run btree_gist or ltree, plan to verify their behavior after the update — these extensions store data in an internal format that may need revalidation, not just a restart. This is the kind of detail that silently breaks replication or an index when ignored.
One fix also deserves attention for high-availability setups: the batch fixes a self-deadlock that could occur while replaying WAL generated by an older minor version, on 14, 15 and 16. In practice, a standby following a primary that stayed on an older minor could freeze. If you upgrade in stages (primary then standby, or the reverse), check replication health after each step.
# 1. Pin the exact version before upgrading
psql -U postgres -d postgres -c "SELECT version();"
# 2. Take a control dump before any minor version bump
pg_dump -U postgres -Fc -f "pre-upgrade-$(date +%F).dump" postgres
# 3. After the upgrade, verify replication and sensitive extensions
psql -U postgres -d postgres -c "SELECT * FROM pg_stat_replication;"
psql -U postgres -d postgres -c "SELECT extname, extversion FROM pg_extension WHERE extname IN ('btree_gist','ltree');"The rule is simple: a PostgreSQL minor never ships “hot” without a control dump and a replication check. Here it matters twice as much, because of those three flagged items.
The trap is also on the client: psql and pg_dump
Two CVEs in this batch carry a reminder many teams forget: the client is part of the perimeter. CVE-2026-18408 (psql \unrestrict) lets a malicious pg_dump server run arbitrary code inside the psql client of whoever restores from it. CVE-2026-19385 hits pg_dump itself with a buffer overflow.
Operationally: never run pg_dump or psql against a server you do not trust, including a backup server or a mirror you believe is clean. An attacker does not need to write to your database to compromise you — they just need you to read from a host they control. That is worth remembering for backup chains and cross-environment migrations.
Verdict
If your instances run version 14, your priority is not the minor release — it is the major migration. Plan it before November 12, 2026: pg_upgrade for large volumes, pg_dump/pg_restore for small ones, and always a test on a copy before cutover. 14.24 is your second-to-last chance to leave while still covered.
If you are already on 15, 16, 17 or 18, apply the matching minor this weekend, not on the next maintenance cycle. A record 28 CVEs — a dozen of them exploitable by a mere authenticated role — leaves no room to wait, and the three post-upgrade items demand a careful deployment, not a blind apt upgrade.
The bigger signal goes beyond PostgreSQL: unsafe memory remains the most reliable reservoir of flaws in the database ecosystem. Every patch batch like this is another argument for watching the projects rewriting these layers in memory-safe languages — and for treating your databases as what they are: critical systems on a support countdown, not bricks you forget about.