Research

PostgreSQL Fixed 52 Flaws. One Lets a Database Login Run Code on the Server. Upgrade to 18.7, 17.12, 16.16 or 15.20.

Patrick Duggan · · 6 min read

PostgreSQL Fixed 52 Flaws. One Lets a Database Login Run Code on the Server. Upgrade to 18.7, 17.12, 16.16 or 15.20.

Upgrade PostgreSQL to 18.7, 17.12, 16.16, 15.20 or 14.25, matching the major version you run, and rebuild or update every C-language extension at the same time. Start with any server where people or applications you do not fully trust can log in: multi-tenant platforms, shared analytics databases, SaaS products that hand customers their own database role, and anything that runs SQL written by someone else. The November 12 release fixes 52 security flaws. The worst, CVE-2026-6460, lets a role that can create objects run code on the host as the operating system user that runs PostgreSQL. If you are on PostgreSQL 13 or older, there is no fix, and 14.25 is the last release PostgreSQL 14 will get.

If your database is managed (Amazon RDS or Aurora, Azure Database for PostgreSQL, Google Cloud SQL or AlloyDB, Supabase and the rest), check your provider's console or security bulletin for the new minor version and apply it when offered. We did not find per-provider patch status in the sources we read, and we are not going to guess it.

Diagram: PostgreSQL's November 12, 2026 release. Left column lists fixed versions 18.7, 17.12, 16.16, 15.20 and 14.25, the need to rebuild C extensions, and that 13 and older get no fix. Center column shows that 44 of the 52 CVEs need a database login, 3 need an administrator, and 5 need no login, of which only one, a PostgreSQL 18 restart flaw, needs no user action. Right column shows the CVE-2026-6460 chain: a login role changes a composite type while a value is held, the stale value is read as the new type, and code runs as the operating system user running PostgreSQL.

What PostgreSQL says

We read the release announcement, the security index and the CVE-2026-6460 page on postgresql.org, and the 18.7 release notes, on November 13.

The announcement, posted November 12 (a Thursday): "This release fixes 52 security vulnerabilities and over 140 bugs reported over the last several months." It lists all 52 with scores. PostgreSQL rates 32 of them at CVSS 3.1 8.8, the highest score in the release.

On CVE-2026-6460 the project's own page says: "Type confusion in PostgreSQL allows an object creator to execute arbitrary code as the operating system user running the database, via ALTER ... SET DATA TYPE primarily." It names another route: "ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN". The cause, in its words: "The system had inadequate tracking of typed values, and values were not self-identifying." Score 8.8, vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, component "core server". Fixed in 18.7, 17.12, 16.16, 15.20 and 14.25, all published 2026-11-12.

The release notes add the part that is easy to miss. The fix introduces versioning so the server can spot values that no longer match their type, and "For full protection, this change requires rebuilding C-language extensions, and there are some extensions that will require source-code changes." A new server setting, composite_type_mismatch, can turn the checks off, "but doing so carries security risks." Leave it alone.

The release notes credit more than a dozen reporters for CVE-2026-6460, among them Mehmet Ince, the OpenAI Security Research Team, the Anthropic OSS program, Claude and Ada Logics. The project treats it as one umbrella CVE for a family of related composite-type problems.

Where "22 years old" comes from

Not from postgresql.org. Mehmet Ince's writeup, published this week, dates the underlying weakness to a commit of May 5, 2004, when PostgreSQL gained ALTER TABLE ... ALTER COLUMN ... TYPE. The technique he used to reach code execution relies on a later commit, from May 14, 2015. He writes that he could "trigger this crash as a lowest-privileged login role", and says he gave working proofs of concept to managed providers in August, naming AWS (Aurora and RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Ubicloud and ClickHouse among those briefed. The Hacker News reports that his published writeup includes the SQL that crashes an unpatched server and a step that leaks memory addresses, but not the final step that runs a command. We read the writeup only for the dates, the privilege quote and the disclosure timeline.

How much access an attacker needs

This is the question that decides your priority, and the sources do not fully agree.

  • PostgreSQL says "an object creator" and scores privileges required as Low: an authenticated role, not an administrator.
  • The researcher says he crashed servers as a lowest-privileged login role. A crash is not code execution.
  • The Hacker News reports Red Hat's assessment as needing a login that can create or modify objects, and says none of the sources it read settles whether a role with only default privileges can get past the crash to run code. We did not find that settled either.

Our reading: by default PostgreSQL lets every role create temporary objects in any database it can connect to, so "object creator" probably covers most login roles on a default install. Treat any login as enough until someone shows otherwise.

Across all 52 flaws, PostgreSQL's own vectors show the same shape. 44 require a login (PR:L), 3 require high privileges such as a database owner (PR:H), and 5 require no login (PR:N). Of those five, only one is a server flaw that a stranger can trigger with no help: CVE-2026-116322, scored 5.3, where a pre-authentication cancel request can leak a spinlock on PostgreSQL 18. The other four need someone to act. Three are in client tools: pg_restore can run code from a crafted archive (CVE-2026-116314, 8.8), psql can run commands from the restore script in a crafted pg_dump tar file (CVE-2026-116330, 8.8), and pg_basebackup can treat backup manifest content as a format string (CVE-2026-16240, 3.7). The fourth, CVE-2026-120145 (8.8), lets a logical replication publisher write to a subscriber's system catalogs, so it needs a subscriber that connects to a hostile or compromised publisher.

Three of the client-tool fixes are about trust in the other direction: a database owner can run code as whoever runs vacuumdb --missing-stats-only (CVE-2026-116313, PostgreSQL 18 only), and SQL injection through object names reaches reindexdb (CVE-2026-116325) and pg_dump (CVE-2026-116318, PostgreSQL 18 only). If your operators run maintenance tools against databases that tenants own, update the client tools on those machines too.

What is not known

  • Exploitation. PostgreSQL's announcement and security pages do not report attacks, and The Hacker News says the project has reported none. None of the 52 CVEs is in CISA's Known Exploited Vulnerabilities catalog as of version 2026.11.13. That means exploitation has not been reported in the sources we read, not that it is not happening.
  • Whether default privileges are enough for code execution, as above.
  • Managed provider status. The researcher says providers were briefed in August and that some built their own mitigations before the upstream release. Which services are fixed today, and on what schedule they roll the new minor versions, is not public in what we read.
  • A workaround. The announcement and release notes give none.

If you cannot patch today

There is no published workaround, so these reduce exposure, they do not fix anything:

  • Cut who can log in. Review pg_hba.conf and the roles that can connect. Disable roles that are not used. Keep the database off the public internet: none of the serious flaws is reachable without a login, so the population that can attack you is the population that can authenticate.
  • Take away creation rights where you can. Revoking CREATE on schemas and TEMPORARY on databases from PUBLIC and from application roles narrows who counts as an "object creator". This is our inference from the advisory's wording, not a mitigation PostgreSQL states, and it may break applications that use temporary tables. Test it first.
  • Do not restore dumps or archives from sources you do not trust with an unpatched pg_restore or psql, and do not point logical replication subscribers at publishers you do not control.
  • Watch the server process. Repeated backend crashes ("server process ... was terminated by signal") in the PostgreSQL log, especially from one role running ALTER on types or columns, are worth a look. That is our suggestion, not a published indicator.

After you patch

The announcement lists post-update steps that are separate from security: reindex GIN indexes you suspect are corrupted, reindex pg_trgm GiST indexes using gist_trgm_ops, reindex B-tree indexes on bpchar columns declared without a length, and take a new full backup if you use incremental backups. If you skipped earlier minor releases, their post-update steps apply too. Rebuild C extensions in the same maintenance window, and if PostgreSQL runs under something other than the package's own service unit, such as Patroni, restart it so the new binaries are actually running.

How we know

We read the postgresql.org release announcement, the security index, the CVE-2026-6460 page and the 18.7 release notes, the CISA KEV JSON feed (catalog version 2026.11.13), and Mehmet Ince's writeup, all on November 13. The Hacker News article led us to it, and we cite it for Red Hat's assessment, which we did not read ourselves. The counts above (44, 3, 5 and 32) are our tally of the 52 CVEs in the announcement, using the CVSS vectors on PostgreSQL's security index.

Our edge instruments watch HTTP traffic to web properties. These flaws live in the PostgreSQL wire protocol and in SQL run by an authenticated role, so our edge would not see an attempt, and we make no claim either way about whether anyone is trying them. No indicators were published in the sources we read, so nothing was added to our feed.

Sources

If this was useful, or if it wasn't, the rating widget below takes ten seconds and is the only way we know.

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register