PostgreSQL has released security updates addressing 52 vulnerabilities, including a critical type confusion flaw that could allow an authenticated database user to execute arbitrary code on the server.
The vulnerability, tracked as CVE-2026-6460, carries a CVSS severity score of 8.8 and has existed in PostgreSQL for more than two decades. It affects users who have permission to create database objects and could enable them to execute code with the privileges of the operating system account running PostgreSQL.
The PostgreSQL Global Development Group released the patches on November 12, 2026, alongside fixes for 51 other security issues. However, administrators must also rebuild C-language extensions installed on affected servers to ensure the vulnerability is fully addressed.
The flaw affects PostgreSQL versions earlier than 18.7, 17.12, 16.16, 15.20 and 14.25. The development team has not reported any evidence that the vulnerability has been exploited in real-world attacks. The US Cybersecurity and Infrastructure Security Agency (CISA) also currently lists exploitation as unreported.
The security weakness stems from how PostgreSQL handles composite data types, which are structures made up of named fields with individual data types.
Under certain conditions, the type assigned to a field can be changed while older values remain stored elsewhere within the database server. This can cause PostgreSQL to interpret an existing value using a different data type, potentially creating an opportunity for an attacker to execute malicious code.
The latest security update introduces additional version checks designed to detect situations where stored values no longer match their expected data types.
Security researcher Mehmet Ince published a technical analysis this week demonstrating how the vulnerability could be exploited on PostgreSQL 18.6.
His technique involves preparing a database query that stores a value, changing the data type of one of its fields and subsequently executing the query. The researcher also demonstrated how the method could be used to crash an unpatched server and expose memory addresses.
However, his published demonstration did not disclose the final SQL command used to achieve remote code execution.
Ince said he was able to trigger the initial crash using a database account with the lowest level of privileges. PostgreSQL’s security advisory, however, describes the attacker as someone with permission to create database objects without specifying the exact privilege level required.
Red Hat’s assessment states that exploitation requires a database login with the ability to create or modify objects. Neither assessment clearly establishes whether an account with only default permissions can progress beyond crashing the server to executing arbitrary code.
According to Ince, the vulnerability‘s origins date back to May 5, 2004, when PostgreSQL introduced the ability to change the data type of a database column. The technique used to turn the weakness into a code execution vulnerability also depends on another modification introduced on May 14, 2015.
The researcher further disclosed that he adapted the exploit for managed PostgreSQL services and privately shared proof-of-concept demonstrations with the security teams of several providers in August.
The companies and platforms involved included Amazon Web Services’ Aurora and RDS, Microsoft Azure PostgreSQL, Google AlloyDB, Supabase, Databricks and Ubicloud. However, the published research did not provide the current patch status of each service.
PostgreSQL credited more than a dozen researchers and security contributors for reporting CVE-2026-6460. Ince was also acknowledged for reporting five additional vulnerabilities addressed in the same release.
Of the 52 vulnerabilities fixed, PostgreSQL assigned a CVSS score of 8.8 to 32 of them, making that the highest severity rating among the issues addressed.
The release also includes a separate vulnerability, CVE-2026-116322, which can allow an unauthenticated remote client to trigger a restart of PostgreSQL 18 servers without requiring a login or user interaction.
Several other security fixes affect PostgreSQL client utilities rather than the database server itself.
One vulnerability allows a specially crafted archive to cause the pg_restore utility to execute malicious code with the privileges of the user running the tool. Another involves a compromised source server manipulating a restore script contained in the tar output generated by pg_dump, potentially causing psql to execute unauthorised commands.
What PostgreSQL Administrators Should Do
Administrators are advised to install the appropriate security update for their PostgreSQL version. The patched releases are 18.7, 17.12, 16.16, 15.20 and 14.25.
They should also rebuild or update all installed C-language extensions alongside the database server. Although extensions compiled against earlier PostgreSQL releases may continue to load, they might not receive the protection introduced by the latest security fixes. Some extensions may require changes to their source code before they can be rebuilt successfully.
Administrators should also be aware that extensions rebuilt for the latest releases may fail to load on older PostgreSQL installations. Extension packages distributed through the project’s RPM repositories now require the corresponding updated minor release.
For systems running PostgreSQL outside its standard package service unit, including deployments managed through Patroni, administrators are advised to restart the database immediately after applying the updates.
Client utilities, including pg_dump, pg_restore, reindexdb and vacuumdb, should also be updated on every machine where they are installed and executed.
The development team has warned against using the new composite_type_mismatch setting to disable the additional validation checks, noting that doing so could introduce security risks. No workaround has been provided for systems that cannot immediately install the patches.
Another important consideration is that PostgreSQL 14 has reached end-of-life, with version 14.25 serving as its final release. Older major versions that are also affected will not receive further security updates.
Following installation of the patches, administrators should carry out the reindexing procedures outlined in the official release announcement. Organisations using incremental backups are also advised to create a fresh full backup and use it as the foundation for subsequent incremental backup operations.