PostgreSQL fixes 52 security flaws; the worst, CVE-2026-6460, lets a database user run code on the server

What happened

On Thursday 12 November 2026 the PostgreSQL Global Development Group released updates for every supported branch: 18.7, 17.12, 16.16, 15.20 and 14.25, plus the second release candidate of PostgreSQL 19. They fix 52 security vulnerabilities (CVEs) and, according to the announcement, more than 140 other bugs.

These are minor releases: stop the server and replace the binaries – no dump and restore or pg_upgrade is needed. Because of the CVE-2026-6460 fix, however, C-language extensions need to be rebuilt, and depending on your setup some indexes should be rebuilt after upgrading.

The announcement does not mention exploitation. PostgreSQL 14.25 is the final release of the 14 branch – it will receive no further fixes.

Technical details

The details come from the PostgreSQL security advisory, the 18.7 release notes and the NVD record. We do not publish exploitation steps.

CVE-2026-6460 (CVSS 3.1 8.8, CWE-843 – type confusion): a user who can create objects can execute arbitrary code as the operating system account running the database. The main route is ALTER … SET DATA TYPE (changing the data type of a column or composite type); the project also lists other DDL sequences, such as adding a column, rolling back and adding a column again.

The root cause: PostgreSQL did not adequately track the type of stored values, and the values did not identify their own type. After a type's layout changed, stale values with the old layout could survive in the system – in catalog entries, PL/pgSQL variables and elsewhere. When the server read them using the new layout, it misread memory. Composite types altered while queries were using them were the most dangerous case.

According to the release notes, the fix:

• introduces versioning of composite values, so the server can detect a value that doesn't match the current type descriptor,
• adds locking (for example against ALTER TYPE on a type used by a CREATE TABLE that hasn't committed yet),
• tightens when ALTER COLUMN TYPE is allowed if something depends on the type (such as a function's default expression),
• adds a composite_type_mismatch server parameter that disables the checks – at a security cost.

The bug was reported by a long list of researchers and teams, including OpenAI Security Research, the Anthropic OSS program and Ada Logics.

Other flaws in the same release (selection):

In total 32 flaws score 8.8 and most of them, by the project's descriptions, lead to code execution; most of the bugs require an authenticated database user, typically one who can create objects.

Who is affected

• Most at risk are servers where untrusted or less trusted users can create objects: shared database hosting, multi-tenant applications, analytics environments where analysts create their own tables, and applications that use one all-powerful account.
• C-language extensions (your own and third-party) need to be rebuilt against the new release; the project says some will need code changes.
• The pg_dump, pg_restore, reindexdb and vacuumdb bugs also affect client packages – admin workstations, backup servers and CI jobs that restore backups.
• Older branches (13 and earlier) are no longer supported and get no fixes.

How to tell if you were compromised

The project has not published indicators of compromise and reports no exploitation. What we suggest checking (our own advice, not the project's):

• Who can create objects: review CREATE privileges on schemas (\dn+ in psql), schema owners, and roles with CREATEDB or CREATEROLE (\du).
• Unusual DDL in the logs: temporarily set log_statement = 'ddl' and look for repeated ALTER … TYPE and ALTER TABLE … ADD COLUMN with ROLLBACK from application accounts that don't normally change the schema.
• Backend crashes in the server log (server process … was terminated by signal 11) – type confusion and use-after-free bugs often show up as crashing processes.
• Child processes and files of the postgres account: unknown processes running as the database user, new files outside the data directory, new cron jobs.

You can break down the CVSS vector in our CVSS calculator.

What to do

1. Upgrade the server to 18.7, 17.12, 16.16, 15.20 or 14.25 (distribution or PGDG packages). Check with SELECT version();.
2. Rebuild C extensions – update extension packages together with the server and recompile your own. Only disable checks with composite_type_mismatch temporarily and knowing the risk.
3. Update client tools (pg_dump, pg_restore, reindexdb, vacuumdb) on workstations, backup servers and in CI. Don't restore backups from untrusted sources.
4. Limit who can create objects: application accounts shouldn't own schemas or hold CREATE unless they need it; run schema migrations with a separate account.
5. After upgrading, follow the announcement's steps: reindex GIN indexes if you suspect corruption, pg_trgm GiST indexes using gist_trgm_ops, tables reporting missing chunk number errors, and B-tree indexes on bpchar columns declared without a length; if you use incremental backups, take a new full backup; and check NOT NULL NO INHERIT constraints on partitioned tables.
6. PostgreSQL 14: plan a move to a newer major version – there will be no more fixes.

Timeline

Updates

• 13 Nov 2026 – first version of this article.