PostgreSQL Patches 52 Flaws, Including 22-Year-Old Bug Enabling Authenticated RCE

A type confusion flaw in PostgreSQL lets a database user who can create objects run code on the server. Updates released on November 13, 2026, fix it, along with 51 other security flaws. Full protection from this flaw also requires rebuilding any C-language extensions installed on the server.

The flaw, tracked as CVE-2026-6460, has a CVSS score of 8.8. Any code run this way has the rights of the operating system user that runs PostgreSQL. All versions before 18.7, 17.12, 16.16, 15.20, and 14.25 are affected.

The PostgreSQL Global Development Group, which publishes the database’s releases, has not reported any attacks using the flaw. CISA’s assessment in the CVE record also lists exploitation as none.

The flaw involves composite types, which are types built from named fields, each with its own data type. A field’s type can be changed while older values of that type are still held in other parts of the server.

The server could then read an old value as if it had the new type. The fix, described in the project’s release notes, adds version checks so the server can detect a value that no longer matches its type.

Security researcher Mehmet Ince described a working exploit for the flaw, demonstrated on PostgreSQL 18.6, in a technical writeup published this week.

His method is to prepare a query that holds a value, change the type of one of the value’s fields, and then run the query. The writeup includes the SQL that crashes an unpatched server this way and a second step that leaks memory addresses. It does not include the SQL for the final step, which makes the server run a command.

He noted that he could “trigger this crash as a lowest-privileged login role.” The project’s security advisory describes the attacker only as someone who can create objects, without saying which privileges that takes.

Red Hat, which ships PostgreSQL packages, says in its CVE assessment that an attacker needs a database login with the ability to create or modify objects. None of these sources says whether an account with only default privileges can go beyond the crash to run code.

Ince traces the root of the flaw to May 5, 2004, when PostgreSQL gained the ability to change a column’s type. His technique for running code relies on a later change made on May 14, 2015.

He also adapted the exploit for managed PostgreSQL services and privately shared proofs of concept with their security teams in August. The providers he worked with include AWS (Aurora and RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks, and Ubicloud. The writeup does not give each service’s current patch status.

The project credits more than a dozen reporters for CVE-2026-6460, including the researcher, and credits him on five other flaws in the same release.

The project rates 32 of the 52 flaws at 8.8, the highest score in the release. Based on the scores in its vulnerability index, only one flaw in the server requires neither a login nor any user action. That flaw, CVE-2026-116322, lets an unauthenticated client trigger a restart of PostgreSQL 18 servers.

Additional Fixes and Recommendations

Several other fixes are in client tools. A crafted archive can make pg_restore run code as the user running it. A compromised source server can make psql run code through the restore script in pg_dump‘s tar output.

Administrators are advised to take the following actions:

• Update the server to versions 18.7, 17.12, 16.16, 15.20, or 14.25, depending on the major version in use.
• Rebuild or update all C-language extensions simultaneously with the server. Extensions built against older releases may still load but might not be protected from the vulnerabilities fixed in this release, as noted in a repository notice.
• Extensions rebuilt for the new releases may fail to load on older servers. Extension packages in the project’s RPM repositories now require the new minor release.
• If PostgreSQL operates outside its package’s service unit, such as under Patroni, restart it immediately after updating, according to a maintainer of the RPM packages.
• Update client tools like pg_dump, pg_restore, reindexdb, and vacuumdb on all machines that utilize them.
• Avoid using the new composite_type_mismatch setting to disable the checks, as this poses security risks.
• The project’s advisory and release notes do not provide a workaround for servers that cannot be updated at this time.
• PostgreSQL 14 has reached end-of-life, with 14.25 being its last release. Older major versions are also affected and have not received updates.
• After updating, follow the reindexing steps outlined in the release announcement. If using incremental backups, take a new full backup and base subsequent incremental backups on it.

Source: The Hacker News