Critical PostgreSQL Type Confusion Vulnerability Enables Server-Side Code Execution

A high-severity type confusion vulnerability in PostgreSQL could allow an attacker with database object-creation privileges to execute arbitrary code on the server. The PostgreSQL Global Development Group has released security updates addressing the flaw, along with 51 other vulnerabilities.

Tracked as CVE-2026-6460, the vulnerability carries a CVSS score of 8.8. Successful exploitation could allow code execution with the operating system privileges of the user running the PostgreSQL service.

The vulnerability affects PostgreSQL versions earlier than:

  • PostgreSQL 18.7
  • PostgreSQL 17.12
  • PostgreSQL 16.16
  • PostgreSQL 15.20
  • PostgreSQL 14.25

The project has not reported any attacks exploiting the vulnerability in the wild. CISA's assessment in the CVE record also currently lists exploitation as none.

How the PostgreSQL Vulnerability Works

CVE-2026-6460 involves a type confusion issue affecting PostgreSQL composite types. Composite types are structures made up of named fields, with each field having its own data type.

The problem occurs when a field's data type is changed while older values using the previous type are still stored elsewhere in the server.

Under certain conditions, PostgreSQL could interpret an existing value using the updated type, even though the value still has its original representation. This mismatch can lead to memory corruption and potentially arbitrary code execution.

The security fix introduces version checks that allow PostgreSQL to identify values whose stored representation no longer matches their current type definition.

Security researcher Mehmet Ince published a technical analysis demonstrating a working exploit against PostgreSQL 18.6.

His technique involves preparing a query that holds a value, changing the type of one of its fields, and then executing the query. The research demonstrates how this process can crash an unpatched server and includes another step that leaks memory addresses.

The published writeup does not disclose the SQL used for the final command-execution stage.

Ince stated that he could trigger the crash using a database account with the lowest privilege level. However, the exact privileges required to progress from triggering the crash to executing code are not fully established in the available advisories.

Red Hat's assessment says exploitation requires a database login with the ability to create or modify objects. The PostgreSQL security advisory describes an attacker who can create objects but does not specify the precise privilege requirements.

A Vulnerability Rooted in Older PostgreSQL Changes

According to Ince's research, the underlying issue can be traced back to changes introduced on May 5, 2004, when PostgreSQL gained support for changing a column's data type.

The technique used to achieve code execution relies on another change introduced on May 14, 2015.

The researcher also adapted the exploit for managed PostgreSQL services and privately shared proof-of-concept material with several providers in August.

The providers included:

  • Amazon Web Services, covering Aurora and RDS
  • Microsoft Azure Database for PostgreSQL
  • Google AlloyDB
  • Supabase
  • Databricks
  • Ubicloud

The published research does not specify the current patch status of each managed service.

PostgreSQL Releases Fix 52 Security Vulnerabilities

CVE-2026-6460 is one of 52 security issues addressed in the latest PostgreSQL release.

The project assigned a CVSS score of 8.8 to 32 of the vulnerabilities, making it the highest score in this release.

Another notable issue, CVE-2026-116322, affects PostgreSQL 18 servers and allows an unauthenticated client to trigger a server restart without requiring user interaction.

The security updates also address vulnerabilities in PostgreSQL client utilities.

For example:

  • A specially crafted archive could cause pg_restore to execute code with the privileges of the user running the utility.
  • A compromised source server could manipulate restore scripts in pg_dump tar output and cause psql to execute code.

These issues highlight the importance of updating both database servers and the client tools used to manage them.

What PostgreSQL Administrators Should Do

Administrators should prioritize installing the appropriate PostgreSQL security release and rebuilding C-language extensions.

Recommended actions include:

  1. Update PostgreSQL: Upgrade to version 18.7, 17.12, 16.16, 15.20, or 14.25, depending on the installed major release.
  2. Rebuild C-language extensions: Rebuild or update all installed C-language extensions alongside the server. Extensions compiled against older releases may continue to load, but they might not receive protection from the vulnerabilities addressed in the update. Some extensions may also require source-code changes.
  3. Check extension compatibility: Extensions rebuilt for the newer releases may fail to load on older PostgreSQL servers. Administrators using the project's RPM repositories should also account for the updated extension package requirements.
  4. Restart PostgreSQL services: If PostgreSQL runs outside its package-managed service unit, such as under Patroni, restart the server immediately after updating.
  5. Update client utilities: Upgrade pg_dump, pg_restore, reindexdb, and vacuumdb on every system where these tools are installed and used.
  6. Keep type checks enabled: Do not use the new composite_type_mismatch setting to disable the checks. PostgreSQL warns that doing so introduces security risks.
  7. Plan updates for systems that cannot be patched immediately: The project's advisory and release notes do not provide a workaround for affected servers.
  8. Account for PostgreSQL 14 end-of-life: Version 14.25 is the final release for PostgreSQL 14. Organizations still using it should plan a migration to a supported major version.
  9. Follow post-update maintenance guidance: Review the release announcement for the required reindexing steps. Organizations using incremental backups should also take a new full backup and base subsequent incremental backups on it.

Why This Matters

CVE-2026-6460 demonstrates how changes to database object definitions and the handling of previously stored values can introduce serious memory-safety issues.

Although exploitation requires database access and the ability to create or modify objects, successful exploitation could move an attacker from database-level access to code execution under the PostgreSQL operating system account.

Organizations should therefore treat this update as a priority, particularly where PostgreSQL hosts production applications, sensitive records, or cloud-connected workloads.

Updating the database server alone is not sufficient for complete protection. Administrators must also rebuild affected C-language extensions, update client utilities, and follow the project's post-update maintenance instructions.