CVE-2026-6460: PostgreSQL RCE Patch

PostgreSQL released security updates for every supported branch on November 12, 2026. The headline fix is CVE-2026-6460, a type-confusion flaw in the core server that lets an object creator execute arbitrary code as the operating system user running the database. The project rates it CVSS 8.8, high severity, with a network attack vector, low privileges, and no user interaction.

Key Takeaways:

• Fixed releases are PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25. Every earlier minor release in those branches is affected.
• The attacker needs a database login that can create objects. That includes temporary objects, and PostgreSQL grants the TEMP privilege on databases to PUBLIC by default.
• Public proof-of-concept code appeared on GitHub on November 13. It is not a turnkey remote exploit, but it shortens the window between patch and attack.
• Upgrade the server, rebuild C-language extensions, and do not disable the new composite_type_mismatch checks to get past breakage.
• PostgreSQL 14 reaches end of life with 14.25. Patching it is temporary; plan the major upgrade.

What shipped, and why this CVE stands out

The November 12 update covers PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25. It closes 52 security vulnerabilities and more than 140 bugs, according to the project announcement. CVE-2026-6460 is one of them, but it is the one most likely to matter outside a laboratory: it is in core PostgreSQL, it does not need an extension, and the condition is object-creation privilege rather than superuser access.

The official advisory describes a type confusion that allows an object creator to execute arbitrary code as the database’s operating system user. The primary route is ALTER ... SET DATA TYPE. The advisory also names other DDL paths, including an ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN sequence.

PostgreSQL 19 RC 2 includes the fixes, but it is still a release candidate; general availability is planned for November 19, 2026. For production, the fixed minor release for your current major is the practical target.

Who can trigger it

The vulnerability is not pre-authentication. An attacker needs a database login and permission to create objects. That sounds narrow until you map it to real deployments. Application roles often receive CREATE on a tenant schema. CI jobs, analytics sandboxes, and developer databases routinely hand out object-creation rights. And the advisory’s “object creator” includes temporary objects.

That last point is the one to check first. PostgreSQL grants CONNECT and TEMPORARY on databases to PUBLIC by default, as the privilege documentation states. A role that can only log in and create temporary objects may therefore meet the condition, unless your team revoked TEMP. The public PoC uses a temporary composite type, which is consistent with that default path.

This is why “we do not let users create tables” is not a sufficient answer. Check both sides: CREATE on schemas and TEMP on databases. A read-only reporting role with the default TEMP grant is more exposed than its name suggests.

The bug, without the exploit

PostgreSQL stores values as Datum objects. A Datum does not carry a self-describing type tag; the surrounding catalog metadata and tuple descriptor tell the server how to interpret those bytes. CVE-2026-6460 is what happens when that metadata changes while an old value is still alive.

The advisory puts it precisely: the system had inadequate tracking of typed values, and values were not self-identifying. Stale values could appear in data dictionary entries, PL/pgSQL variables, and other parts of the system. Change a composite type’s attribute with ALTER ... SET DATA TYPE, then read a value that was captured under the old layout, and the server can apply the new type’s interpretation to the old bytes. That is the type confusion.

The fix is structural rather than a single bounds check. The 18.7 release notes describe new versioning logic for composite datums, locking around concurrent type changes, and tighter dependency rules for ALTER COLUMN TYPE. The release notes also warn that full protection requires rebuilding C-language extensions; some extensions will need source changes.

Researcher Mehmet Ince, one of the reporters credited in the advisory, describes it as a 22-year-old primitive and traces it to composite-type handling from 2004. His writeup covers the path from a crash to code execution. The important operational point is simpler: this is a core-server memory-safety bug.

Public exploit code changes the timeline

Two public GitHub repositories tied to the CVE appeared on November 13, the day after the release. One reproduces a crash against PostgreSQL 17.11 and confirms the fixed behavior on 17.12. The other contains a Python execution attempt that needs the address of system() in the backend process, either supplied by the operator or read from /proc on the same host. It is not a single-request exploit against an arbitrary internet-facing server, but it is more than a theoretical description.

The CVE is not in CISA’s Known Exploited Vulnerabilities catalog as of November 14, 2026, and no in-the-wild exploitation has been publicly reported. FIRST’s EPSS puts the 30-day exploitation probability at 0.59%, around the 49th percentile, as of November 13. The score is low. Public PoC code can still move a vulnerability from “patch on the next maintenance window” to “patch this week,” especially where object-creation rights are broad.

Patch and verify

Inventory first. Run SELECT version(); against every server, not just the primary. Include read replicas, staging, CI databases, container images, and managed instances. A version string such as PostgreSQL 17.11 is affected; 17.12 is fixed. Check the actual engine, not the control-plane version or the client library.

Apply the minor update. These are cumulative minor releases; PostgreSQL does not require a dump and restore or pg_upgrade for a same-major update. Stop the server, update the binaries, and restart. For PostgreSQL 14, 14.25 is the final release; it closes this CVE, but the branch will receive no further security fixes. Treat 14.25 as a bridge to a supported major, not a destination. If you are planning that upgrade, our PostgreSQL 18 New Features for Performance covers what changed in the current major.

Rebuild C extensions. The release notes say full protection for CVE-2026-6460 requires rebuilding C-language extensions, and some extensions may need source changes. Test extensions that ship native code before declaring the fleet patched. If an extension breaks, fix or replace it; do not set composite_type_mismatch to off. The release notes say that parameter disables the new checks and carries security risks.

Read the post-update steps. The same release carries unrelated fixes you must apply with this update. Among them are several index-corruption bugs. The notes call for reindexing affected GIN indexes, pg_trgm GiST indexes, and B-tree indexes on length-less bpchar columns. Users of incremental backups should take a new full backup and use it as the basis for later incrementals. Those steps are separate from the CVE, but they are part of a safe update.

Check managed providers separately. Managed PostgreSQL services may schedule the update on their own timetable. A provider saying “patched” is not the same as your instance running 18.7, 17.12, 16.16, 15.20, or 14.25. Confirm the engine minor version and the extension list in the actual instance.

If you cannot patch today

Patch is the fix. As a stopgap, reduce who can create objects. Revoke CREATE on schemas from roles that do not need it, and revoke TEMP on databases where temporary objects are not part of the workload. Test this before rolling it out: ORMs, migration tools, and reporting jobs sometimes depend on temporary tables.

Audit DDL while you work. Log and review ALTER TYPE and ALTER TABLE ... ALTER COLUMN ... TYPE statements from low-privilege roles, especially changes to temporary types. There is no official indicator-of-compromise list for this CVE, so the useful detective control is visibility into who is changing type definitions and who can create objects in the first place. None of this replaces the update.

Signals to watch

Three things will change the risk picture. First, whether a managed provider or Linux distribution confirms a backport and the exact package version. Second, whether the public PoC matures into a reliable chain that does not need a locally supplied system() address. Third, whether CISA adds the CVE to KEV or EPSS rises sharply. For now, the fixed releases are available and the exposure condition is common enough that inventory should start before those signals arrive.

Sources and References

Sources cited while researching and writing this article:

• PostgreSQL security advisory: CVE-2026-6460
• PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25, and 19 RC 2 released
• PostgreSQL 18.7 release notes
• CVE record: CVE-2026-6460
• NVD: CVE-2026-6460
• GitHub Advisory Database: GHSA-7m3p-q8w8-4qgh
• PostgreSQL documentation: privileges and default PUBLIC grants
• Mehmet Ince: turning the PostgreSQL type-confusion primitive into RCE
• Public PoC repository: chor4o/CVE-2026-6460-POC
• Public crash-lab repository: slabbdev/postgresql-type-confusion-cve-2026-6460
• CISA Known Exploited Vulnerabilities catalog
• FIRST EPSS data for CVE-2026-6460