PostgreSQL 14 EOL Nov 2026: 44 CVEs This Year, One Patch Left

On August 13, 2026, the PostgreSQL project released versions 18.6, 17.11, 16.15, 15.19, and 14.24. The announcement puts it plainly: this release fixes 28 security vulnerabilities and over 110 bugs.

Twenty-eight CVEs is the most PostgreSQL has ever fixed in a single release. The previous record was 11, set one quarter earlier in May. Seventeen of the 28 carry a CVSS score of 8.0 or higher, and nine of them have "executes arbitrary code" right in the title.

And reinforced in the same announcement is a deadline: PostgreSQL 14 will stop receiving fixes on November 12, 2026.

PostgreSQL is not insecure. The opposite, actually. A 28-CVE release is the security process working: researchers are looking harder at Postgres than ever, they are finding real bugs, and the community is fixing them on schedule. The problem starts when your version falls off that schedule. PostgreSQL 14 has one scheduled security release left. After that, every CVE like the ones below stays open on your servers forever.

‍

The CVE curve is bending upward, fast

We pulled the CVE counts for the last six quarterly security releases from the PostgreSQL security page and release announcements. Here is the shape of it:

Add it up by year and the picture gets sharper. All of 2025 produced 7 PostgreSQL CVEs. 2026 has produced 44 so far, with one release round still to go.

Why the jump? The honest answer is attention, not decay. PostgreSQL did not suddenly get worse at writing C. Security researchers and fuzzing pipelines got a lot more interested in it, and the codebase is being audited at a depth it never was before. Look at where these bugs live: to_char(), regular expression matching, tsvector, string escaping. Functions that have been there for years, called by ordinary applications every day.

But that explanation should worry a PG 14 user, not comfort them. Discovery rates driven by researcher attention do not politely stop at your version's EOL date. The same techniques that surfaced 44 CVEs this year will keep surfacing them next year. The only thing that changes on November 12 is that PostgreSQL 14 stops getting the fixes.

‍

What is actually in the batch

A flat list of 28 CVEs is hard to reason about, so we grouped the 2026 vulnerabilities into five themes. The full table, with severity scores and PG 14 applicability, is at the bottom of this post.

1. Memory corruption in functions your app calls every day

This is the dominant class, and it is where most of the CVSS 8.8 scores live. Heap buffer overflows in to_char() (CVE-2026-14669) and regexp matching (CVE-2026-14664). Integer wraparounds that undersize allocations in tsvector and tsquery (CVE-2026-14662). Type confusion reachable through cursor operations (CVE-2026-16239) and function arguments (CVE-2026-14680). These are not exotic admin-only code paths. If your application formats dates or runs regular expressions in SQL, it exercises this code.

2. SQL injection in places your ORM cannot see

Not the injection you test for at the application layer. This is injection through the database's own plumbing: unquoted field names in deparsed EXTRACT() calls (CVE-2026-15741), table names in REFRESH PUBLICATION (CVE-2026-6638), subscription names in pg_createsubscriber (CVE-2026-6476). Parameterized queries and ORM escaping do nothing here, because the injection happens inside PostgreSQL itself.

3. Your client tools are targets too

A recurring 2026 pattern: a compromised or malicious server attacking the tools that connect to it. psql executing data lines as commands after a failed COPY FROM STDIN (CVE-2026-6464), a server superuser running arbitrary code in a connecting psql client (CVE-2026-18408), heap overflow in pg_dump (CVE-2026-19385), libpq stack overwrites via large-object functions (CVE-2026-6477), and pg_basebackup overwriting unrelated client files (CVE-2026-6475). If you run dump/restore pipelines, cross-server replication, or connect to databases you do not fully control, this class is yours.

4. Quiet authentication and privilege gaps

Individually low-scoring, collectively nasty. A user-enumeration oracle in SCRAM authentication (CVE-2026-14672). MD5 password disclosure through a timing channel (CVE-2026-6478). Row-level security decisions served from stale plan caches after role changes (CVE-2026-14666). GSSAPI encryption enforcement bypassed when coupled with SSL (CVE-2026-14681). These are the bugs that turn a foothold into lateral movement.

5. Contrib modules count as attack surface

pgcrypto silently falling back to cleartext for disabled ciphers (CVE-2026-14663). Out-of-bounds writes in fuzzystrmatch (CVE-2026-15742). Buffer overruns in pg_stat_statements (CVE-2026-14676) and pg_trgm (CVE-2026-14678). Plan-cache type confusion in refint (CVE-2026-14671). Run \dx on a typical PostgreSQL 14 instance and you will find several of these installed.

‍

Every one of the 28 affects PostgreSQL 14

Here is the number that matters for anyone still on 14. All 28 CVEs from the August release received patches in 14.24. Check the 14.24 release notes yourself; the whole list is there. Across all of 2026, 40 of the 44 CVEs affected PostgreSQL 14. The four exceptions were bugs in features added in later versions.

A five-year-old branch is not aging out of these vulnerabilities. The bugs being found are in code that has been stable since well before 14 shipped, which means they hit 14 just as hard as 18. The version number does not protect you. The patches do.

‍

These bugs get exploited

If 28 patched CVEs still feels theoretical, look at what happened the last time a PostgreSQL bug met a motivated attacker.

In February 2025, Rapid7 disclosed CVE-2025-1094, a SQL injection flaw in how PostgreSQL's string-escaping routines handle invalid UTF-8. Stephen Fewer found it while investigating the exploitation of a BeyondTrust zero-day (CVE-2024-12356), the vulnerability used in the December 2024 attacks that breached US Treasury workstations, attributed to suspected Chinese state-sponsored actors. Rapid7's finding: in every scenario they tested, exploiting the BeyondTrust flaw required exploiting the PostgreSQL flaw too. A Postgres bug was load-bearing in a nation-state intrusion, as a zero-day, months before anyone knew its CVE number.

PostgreSQL fixed it within weeks, in 17.3, 16.7, 15.11, 14.16, and 13.19. Notice that last one. PostgreSQL 13 got the fix because it was still inside its support window, with nine months to spare. Had the same bug surfaced in 2026, every PostgreSQL 13 server on earth would still be exploitable today, with no patch coming, ever. That is the exact position PostgreSQL 14 will be in after November 12.

‍

The math after November 12

PostgreSQL's versioning policy is unambiguous: five years of support, then one final minor release, then nothing. For PostgreSQL 14, that final release lands on November 12, 2026.

Now run the numbers forward. In 2026, PostgreSQL has fixed CVEs at a pace of roughly 40 per year that apply to version 14, and the discovery rate is accelerating, not slowing. A PostgreSQL 14 instance frozen at its final release will accumulate dozens of known, documented, unpatched vulnerabilities within its first year past EOL. A meaningful share of those will be CVSS 8.0 or higher. And each one ships with a public description and a public fix commit in newer branches, which is to say, a map for anyone who wants to write an exploit against the versions that never got the fix.

Quarterly PostgreSQL security releases keep coming after November. For PostgreSQL 14 users, they just turn into a growing list of things you cannot patch.

‍

If upgrading were easy, you would have done it already

Nobody runs a five-year-old database version out of laziness. Major-version PostgreSQL upgrades are real projects: extension compatibility checks, logical replication cutovers or dump-and-restore downtime, query plans that shift under the new optimizer, driver and ORM regression testing across every service that touches the database. Some teams are pinned by a vendor application certified only against 14. Others have change windows measured in quarters, or an estate of hundreds of instances where "just upgrade" is a year of engineering.

Those are legitimate constraints. The November 12 deadline does not care about any of them.

‍

Two ways forward

If you can get to PostgreSQL 16, 17, or 18 before November, do it. That is the community's recommendation and it is ours too. The official upgrade documentation covers the paths, and every version you gain buys you years of scheduled fixes.

But if the upgrade will not land before the deadline, do not let PostgreSQL 14 go dark. HeroDevs Never-Ending Support for PostgreSQL keeps post-EOL PostgreSQL 14 patched against exactly the kinds of vulnerabilities in this post, with security fixes delivered after the community stops shipping them. You get time to do the migration right, without running a database whose CVE list only grows.

PostgreSQL 14 has one security release left. Make sure it is not the last one your database ever gets.

‍

Appendix: every PostgreSQL CVE fixed in 2026