PostgreSQL Just Fixed 52 Security Bugs. Is Your Database Exposed?

PostgreSQL 18.7, 17.12 and friends fix 52 CVEs, 32 rated 8.8, and PostgreSQL 14 is now end-of-life. Here's who is exposed, what to reindex and what to do next.

TheTechLane pharmacy prescription label cover in cream and green with a large TL logo seal, the headline PostgreSQL just fixed 52 security bugs and dosage lines per version

The PostgreSQL Global Development Group shipped PostgreSQL 18.7, 17.12, 16.16, 15.20 and 14.25 on Thursday, November 12, 2026, closing 52 security vulnerabilities and more than 140 other bugs in one go. Thirty-two of those CVEs score 8.8 out of 10. And for anyone still on PostgreSQL 14, this is the last patch you'll ever get.

Here's what you need to know:

  • 52 CVEs are fixed across every supported branch. By our count of the official list, 27 of them are described as able to execute, or possibly execute, arbitrary code.

  • Thirty-two CVEs carry a CVSS v3.1 score of 8.8, the highest in the batch. The lowest, an EXECUTE privilege bypass on cast functions, scores 3.1.

  • Client tools are affected too. pg_dump, pg_restore, reindexdb and vacuumdb all had bugs, so updating the server alone isn't enough.

  • Some fixes need manual work after the upgrade, including reindexing certain GIN, pg_trgm GiST and bpchar B-tree indexes, and taking a fresh full backup if you use incremental backups.

  • PostgreSQL 14 is now end-of-life. PostgreSQL 19 RC 2 also shipped, with general availability planned for November 19, 2026.

UML sequence diagram of the PostgreSQL pg_dump SQL injection CVE-2026-116318: a low-privilege role creates a child table with a crafted NOT NULL constraint name, an admin dumps the database with an unpatched pg_dump and restores it, and the injected SQL runs as the restoring user until both server and client binaries are updated

How a crafted constraint name turns a pg_dump restore into SQL injection

What Happened

The release landed on November 12 in the official PostgreSQL release announcement. It covers every supported version at once, plus the second release candidate of PostgreSQL 19, and the project says it "fixes 52 security vulnerabilities and over 140 bugs reported over the last several months."

That's an unusually heavy minor release. It reads less like routine maintenance and more like the results of a full security audit.

The bugs cluster in a few places. As Help Net Security summed it up, most of the code execution flaws are memory errors or type confusion, where PostgreSQL treats a value as the wrong data type. They show up in PL/Perl and PL/Tcl, text search functions such as ts_rank_cd(), parallel query, logical replication, dblink and statistics import.

Take the first bug on the list. CVE-2026-6460 is a type confusion after ALTER ... SET DATA TYPE. According to the advisory, it "allows an object creator to execute arbitrary code as the operating system user running the database." Its CVSS vector is AV:N/AC:L/PR:L/UI:N, which means it's reachable over the network with low privileges and no user interaction. It affects every version before 18.7, 17.12, 16.16, 15.20 and 14.25.

That "object creator" detail matters. These aren't bugs an anonymous stranger can fire at your port 5432. Most need a logged-in role that can create objects or run SQL. But on a shared database, a multi-tenant SaaS, a hosted notebook, or any app where users can define functions or schemas, that bar is low.

The client tools got hit as well. CVE-2026-116318 is a SQL injection in pg_dump that "allows an object creator to execute arbitrary SQL as the user restoring the dump," through a not-null constraint name that needs quoting. It only affects PostgreSQL 18 before 18.7. Separately, pg_dump's tar-format restore.sql failed to block psql command injection (CVE-2026-116330), pg_restore could execute arbitrary code because it didn't validate non-plain archives (CVE-2026-116314), and reindexdb mishandled index name quoting (CVE-2026-116325, CVSS 8.0).

There's a quieter category too. CVE-2026-116311 lets DROP OWNED remove restrictive row security policies from tables the user doesn't own, and CVE-2026-120154 lets INSERT ... ON CONFLICT read rows despite row security policies. If your app leans on row-level security for tenant isolation, those deserve a close look.

Why so many at once? Phoronix notes that PostgreSQL developers, "like many in the open-source world, have been hammered by bug reports and security findings fueled by AI/LLMs," and that PostgreSQL 19 has been running weeks behind schedule because of that burden. The PostgreSQL project itself doesn't say where the reports came from.

Why It Matters

PostgreSQL is the default database for a huge slice of modern software, from Rails and Django apps to Supabase-style backends and the pgvector stores behind many RAG pipelines. A batch this size touches nearly every backend team.

The scary number isn't 52. It's the 8.8. A score that high, with low privileges required, describes a path from "can run SQL" to "runs code as the postgres OS user." From there, an attacker can read data files, steal credentials on the box, or move sideways into the rest of your network.

This also exposes a common blind spot: the trust boundary inside the database. Many teams harden the network edge and then hand broad CREATE rights to app roles, migration tools, analysts and third-party integrations. Every one of those roles is a potential "object creator" in the advisories' language.

The backup angle is just as important. Among the bug fixes, the project lists "several fixes for incremental backups that could produce corrupt backups," fixes for base backups, and a bug where a parallel pg_dump against a standby could corrupt both the dump and the standby's data. A backup you can't restore is worse than no backup, because it gives you false confidence.

Then there's PostgreSQL 14. The PostgreSQL versioning policy supports each major version for five years, then ships a final minor release. 14.25 is that release. Any CVE found after November 12 in a version 14 code path stays unfixed.

We saw something similar with the Next.js and React critical RCE patch: the fix is easy, but finding every place the vulnerable version runs is the real work.

What It Means for Developers

Minor releases are low-risk to install. The versioning policy says you don't need a dump and restore: "you simply stop the database server, install the updated binaries, and restart the server." The release notes still matter, because this one has follow-up steps.

  • Patch the server now. Move to 18.7, 17.12, 16.16, 15.20 or 14.25, depending on your branch. Check with SELECT version();.

  • Patch the clients too. Update the pg_dump, pg_restore, psql, reindexdb and vacuumdb binaries in your CI images, backup jobs, Docker images and laptops. Old client binaries stay vulnerable even when the server is new.

  • Don't restore untrusted dumps with old tools. Several of the client bugs run code or SQL as the user doing the restore. Treat a dump from someone else's database like untrusted input.

  • Run the post-update steps that apply to you. Reindex suspect GIN indexes, pg_trgm GiST indexes using gist_trgm_ops, and B-tree indexes on bpchar columns declared without a length (plain char(n) columns aren't affected). Run REINDEX TABLE on any table that throws "missing chunk number" errors.

  • Take a fresh full backup if you use incremental backups, then base future incrementals on it.

  • Check partitioned tables for NOT NULL NO INHERIT constraints, which this release now disallows on partitioned tables.

  • Audit who can create objects. Revoke CREATE on schemas and databases from roles that don't need it, especially app and reporting roles.

  • Plan your exit from PostgreSQL 14. Pick a target (17 or 18 today, 19 after it ships), rehearse pg_upgrade or a logical replication cutover on a copy, and put a date on it.

Here are the post-update checks the project published, ready to paste into psql:

-- Reindex a GIN index you suspect is corrupted
REINDEX INDEX your_index_name;

-- Fix "missing chunk number" errors (also reindexes the TOAST table)
REINDEX TABLE your_table_name;

-- Find NOT NULL NO INHERIT constraints on partitioned tables
SELECT conrelid::regclass, conname
FROM pg_constraint
WHERE contype = 'n' AND connoinherit
  AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p');

The project says you can drop unwanted constraints with ALTER TABLE ... DROP CONSTRAINT, or keep them with ALTER TABLE ... ALTER CONSTRAINT ... INHERIT, which fails if any partition holds NULLs in that column. If you skipped earlier minor releases, read their release notes too, because their post-update steps still apply.

On a managed service like Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL or Supabase, the provider rolls out the binaries, but the reindex and backup steps are still yours. Check your provider's maintenance window and version list rather than assuming you're covered.

If your RAG stack stores embeddings in PostgreSQL, our guide to vector databases explains where that layer sits, and why it deserves the same patching discipline as your main app database.

Flowchart for applying the November 2026 PostgreSQL security update: pick your major version, install the new minor release, stop and restart with new binaries, update client tools like pg_dump and psql, then reindex GIN, pg_trgm GiST and bpchar B-tree indexes, reindex tables with missing chunk errors, take a new full backup, fix NOT NULL NO INHERIT constraints and audit roles that can create objects

Your PostgreSQL patch-day checklist, step by step

What's Next

PostgreSQL 19 should reach general availability on November 19, 2026, unless an issue forces a delay. If you tested 19, note that RC 2 reverts support for JSON_ARRAY() and JSON_OBJECT() over arrays, composite types and range types in expression indexes, generated columns and partition keys. Objects built that way must be dropped or redefined before you upgrade, or pg_dump, pg_restore and pg_upgrade will fail to recreate them.

The open question is pace. If AI-assisted bug hunting keeps finding flaws at this rate, as Phoronix suggests, teams should expect bigger minor releases and treat them as routine work, not rare events. We saw what happens when nobody checks a database closely in Jepsen's 96-bug report on ParticleDB. PostgreSQL's response is the opposite: find them, fix them, publish them all at once.

What the project hasn't said is whether any of these bugs were exploited in the wild. Nothing in the announcement suggests active attacks, but that's no reason to wait.

FAQ

Do I need to dump and restore my database to apply this update?

No. These are minor releases, so you stop PostgreSQL, install the new binaries and restart. Some users then need extra steps, such as reindexing certain indexes or taking a new full backup.

Can an attacker exploit these bugs without a database login?

Mostly not. The advisories we checked need a low-privilege role, often one that can create objects. One bug, CVE-2026-116322, involves a pre-authentication cancel request that can leak a spinlock, scored 5.3.

Is PostgreSQL 14 still safe to run?

It's patched up to 14.25, but that's the final release. Any vulnerability found from now on won't be fixed in 14, so plan a major-version upgrade soon.

Want the next database security alert before it hits production? Subscribe to the free TheTechLane newsletter for developer-focused security news, patch checklists and tutorials, straight to your inbox.

Sources

Follow TheTechLane

Keep learning AI, development, and modern developer technologies with TheTechLane.

Learn • Build • Share

Follow @thetechlanehq for more developer guides, tutorials, and practical technology content.