PostgreSQL patches 52 flaws, headlined by CVE-2026-6460 RCE bug

PostgreSQL issued updates fixing 52 security flaws. CVE-2026-6460 leads the batch, a type-confusion flaw carrying a CVSS score of 8.8 that lets any database user able to create objects run code at the server’s operating system privilege level.

The flaws affect all releases older than 18.7, 17.12, 16.16, 15.20, and 14.25. The fixed releases are 18.7, 17.12, 16.16, 15.20, and 14.25. Server admins should move to the version matching their major version line. The flaws also affect older major versions, but those versions received no update, and PostgreSQL 14 is end-of-life with 14.25 as its final release.

Full protection requires rebuilding installed C-language extensions as well as applying the patch. Older extensions still load after the update yet may lack protection for the fixed issues, and some extensions need source-code changes. An extension rebuilt for the new releases may not load on an older server.

The project’s RPM repositories now require extension packages to use the new minor release. Restart PostgreSQL immediately after updating when it runs outside its package service unit, as under Patroni. Client tools including pg_dump, pg_restore, reindexdb, and vacuumdb need updates on every machine where they run.

The PostgreSQL Global Development Group has not reported any attacks using the flaw. CISA lists exploitation as none in its assessment of the CVE record. The flaw dates to a May 5, 2004, change letting PostgreSQL alter a column’s type. A change made on May 14, 2015, underlies the technique used to run code.

Composite types contain named fields, and each field carries its own data type. Changing a field’s type can leave older values of that type in other server locations. The server might read an old value as though it had the new type. Version checks added by the fix let the server spot a value whose type no longer matches.

Mehmet Ince, a security researcher, published a write-up this week describing a working exploit demonstrated on PostgreSQL 18.6. His method prepares a query holding a value, changes one field’s type, then runs the query. He said, “trigger this crash as a lowest-privileged login role.”

The write-up includes SQL for crashing an unpatched server and for leaking memory addresses in a second step. The final-step SQL that makes the server run a command is not included in the write-up. In August, Ince privately shared proof-of-concept code with the security teams of managed PostgreSQL providers, including AWS with Aurora and RDS, Microsoft with Azure PostgreSQL, Google with AlloyDB, Supabase, Databricks, and Ubicloud. The write-up does not list the patch status of each managed service.

Red Hat states that exploiting requires a database login with create or modify object ability. The project’s security advisory characterizes the attacker solely as someone able to create objects and omits the privileges involved. It is unclear whether default-privilege accounts can advance from crashing the server to running code.

The project credits over a dozen reporters for the flaw and names Mehmet Ince among them, also crediting him for five other flaws in this release. 32 of the 52 flaws carry an 8.8 rating, the top score for this release. According to its vulnerability index scores, just one server flaw needs no login and no user action. CVE-2026-116322 lets an unauthenticated client restart PostgreSQL 18 servers.

Client tool fixes include pg_restore running code from a crafted archive as the user executing it. The restore script inside pg_dump’s tar output can carry code from a compromised source server that psql then runs. Following the update, admins should apply the reindexing steps from the release announcement. Incremental backup users should make a new full backup and use it as the base for later incrementals.

The project warns that using composite_type_mismatch to disable the checks creates security risks. The advisory and release notes provide no workaround for servers unable to update yet.