Threat feed

HighCVSS8.8#CVE-2026-6460 #PostgreSQL #database #type confusion #arbitrary code execution #scheduled update #PostgreSQL 14 #end of life

CVE-2026-6460 — PostgreSQL type confusion leads to arbitrary code execution (CVSS 8.8; fixed in 18.7, 17.12, 16.16, 15.20 and 14.25): explainer and fix

CVE-2026-6460: type confusion in PostgreSQL 14 to 18 allows code execution as the OS user (CVSS 8.8). Fixed in November 2026. No exploitation reported.

Published 2026-11-13 Updated 2026-11-13 Last verified 2026-11-13 8 min read

On this page

An explainer on the type confusion flaw leading to arbitrary code execution that PostgreSQL fixed in its November 2026 scheduled update. It covers what happens, who is affected and how to respond, from a defender's point of view and without attack steps.

Advisory summary — ADVISORY

CVE: CVE-2026-6460 (PostgreSQL type confusion after ALTER ... SET DATA TYPE executes arbitrary code)
Severity: CVSS v3.1 8.8 (High; vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; assigned by PostgreSQL)
Type: Type confusion (CWE-843). Executes arbitrary code as the OS user running the database
Condition: Authentication required. An object creator (a low-privilege account)
Affected: PostgreSQL 14 to 18 (before the fixed versions below)
Fix: 18.7 / 17.12 / 16.16 / 15.20 / 14.25 (published 12 November 2026)
Same update: 52 vulnerabilities fixed in total. 14.25 is the last update for PostgreSQL 14
Exploitation: None reported. Not in the 10 November edition of CISA KEV
Workaround: None listed

8.8

CVSS v3.1 (PostgreSQL)

Auth needed

Low-privilege DB account

Fixed in the same update

14 is final

14.25 ends support

PostgreSQL 14 gets no further fixes

The PostgreSQL announcement says 14.25 is the final release of PostgreSQL 14, which will no longer receive security or bug fixes. If you run 14, apply this update and plan a migration to a supported version.

What kind of vulnerability is it

The project describes type confusion (CWE-843) that lets an object creator execute arbitrary code as the operating system user running the database, mainly through ALTER ... SET DATA TYPE. It also says other routes through data definition commands exist. The cause is inadequate tracking of typed values: values did not identify their own type, so stale values could appear in data dictionary entries, PL/pgSQL variables and other places.

The condition is that the account can log in to the database and create objects. In CVSS terms that is low privileges (PR:L) and no user interaction (UI:N).
This site does not describe exploitation steps or which operations are dangerous.
The fix is in the PostgreSQL core. The official page does not say whether extensions or non-default settings are required.
CISA's assessment (SSVC) in the CVE.org record is exploitation: none, automatable: no, technical impact: total.

Affected scope

Item	Detail
Product	PostgreSQL (core)
Affected versions	Before 18.7, 17.12, 16.16, 15.20 and 14.25
Fix (18)	18.7
Fix (17)	17.12
Fix (16)	16.16
Fix (15)	15.20
Fix (14)	14.25 (the last update for 14)
Workarounds / mitigations	None listed

No dump and reload or pg_upgrade is needed. The PostgreSQL announcement says you can simply stop the server and update the binaries.
Version 13 and earlier are already out of support. The official page lists 14 to 18 for this CVE.

Other vulnerabilities in the same update

The 12 November 2026 release (18.7, 17.12, 16.16, 15.20, 14.25) fixes 52 security vulnerabilities and more than 140 bugs. This article focuses on CVE-2026-6460.

For the list of 52 and each CVE's severity and affected versions, see the PostgreSQL security information page.
The list includes different kinds of issue: arbitrary code execution, server memory disclosure, SQL injection and privilege-check bypass. It also includes fixes in client tools (pg_dump, pg_restore, reindexdb and others).
Some fixes need extra steps after updating (rebuilding GIN indexes if corruption is suspected and pg_trgm indexes, taking a new full backup if you use incremental backups, checking constraints on partitioned tables). Follow the "Updating" section of the release announcement.

How to check whether you are affected

Check the PostgreSQL version

Run SELECT version(); to see the server version. 18 below 18.7, 17 below 17.12, 16 below 16.16, 15 below 15.20 or 14 below 14.25 is affected.

Find everywhere it runs

List servers you operate, containers, PostgreSQL bundled inside applications, and development and test environments. For how to keep a list, see the asset inventory checklist.

Check which accounts can create objects

Find the roles that can log in to the database and create or alter tables and other objects. Check whether the accounts your applications use have more privilege than they need.

For managed services, read the provider's announcement

If you use RDS, Cloud SQL or similar, check your instance's version and the provider's status in the provider's announcement.

What to do today

Update the minor version to the fixed release (priority)

Move to the fixed release for your line (18.7, 17.12, 16.16, 15.20 or 14.25) or later. Before updating, confirm that backups exist and can be restored (backup essentials). With replicas, settle the procedure and order first.

Check the post-update steps

In the "Updating" section of the release announcement, check which apply to you: rebuilding GIN indexes if corruption is suspected, rebuilding pg_trgm GiST indexes, and a new full backup if you use incremental backups.

Narrow privileges until you update

The PostgreSQL pages list no workaround. As this site's own addition, until you update, limit accounts that can create objects to the minimum, and do not give the accounts your applications use creation rights they do not need. This is not a measure named in the advisory and does not replace updating.

Confirm managed-service updates

Check the provider's announcement for supported versions and the update schedule. Also check whether automatic minor updates are on and when the maintenance window is.

If you run PostgreSQL 14, plan a migration

After updating to 14.25, plan a move to a supported version. Set a deadline and an owner.

Exploitation status

The PostgreSQL pages mention no exploitation.
CISA's assessment (SSVC) in the CVE.org record is exploitation: none, automatable: no, technical impact: total (dated 12 November 2026).
It is not in the 10 November edition of CISA's KEV catalog.
No public information on the scale, techniques or actors of any attacks could be confirmed.
Several researchers and organisations reported the issue, and the official page carries acknowledgements.

Sources

PostgreSQL — CVE-2026-6460 (description, affected and fixed versions, CVSS 8.8, 12 November 2026)
PostgreSQL — PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25, and 19 RC 2 Released! (52 fixes, PostgreSQL 14 end of life, post-update steps)
PostgreSQL — Security Information (the list of 52)
CVE.org — CVE-2026-6460 (published 12 November 2026; CWE-843, CISA SSVC assessment)
CISA KEV — Known Exploited Vulnerabilities Catalog (not listed in the 10 November edition of the catalog)

Limiting object-creation privileges is listed here by this site as a general defence; it is not a workaround stated by PostgreSQL. Last verified: 13 November 2026.

FAQ

QWhat is CVE-2026-6460?

Type confusion in PostgreSQL (CWE-843). According to the project, an object creator can execute arbitrary code as the operating system user running the database, mainly via ALTER ... SET DATA TYPE. The cause is described as inadequate tracking of typed values: values were not self-identifying, so stale values could remain. CVSS v3.1 is 8.8 (High).

QCan it be attacked without authentication?

No. The CVSS vector requires low privileges (PR:L), and the project's description refers to an "object creator". That means an account that can log in to the database and create objects. But if such an account is taken over through an application flaw or leaked credentials, it can become a foothold.

QWhich versions are affected, and what is the fix?

PostgreSQL 14 to 18 are affected, fixed in 18.7, 17.12, 16.16, 15.20 and 14.25 (published 12 November 2026). Versions before these are affected. No dump and reload or pg_upgrade is needed: a normal minor update that swaps the binaries applies it.

QIs there a workaround if I cannot update yet?

The PostgreSQL pages list no workaround or mitigation. As this site's own addition, until you update, limit accounts that can create objects to the minimum needed. This is not a measure named in the advisory and does not replace updating.

QIs it already being exploited?

No exploitation is reported. CISA's assessment (SSVC) in the CVE.org record is exploitation: none, automatable: no, technical impact: total. It is not in the 10 November edition of CISA's KEV catalog.

QWhat should I do on managed services such as RDS or Cloud SQL?

The provider announces which versions it offers and when they are applied. Check the provider's announcement for your instance's version and its update schedule, and check whether automatic minor updates are enabled.