On November 12, PostgreSQL released updates fixing 52 vulnerabilities, including CVE-2026-6460: a type confusion flaw that could allow a user able to create objects to execute code with the permissions of the system account running the database. Replacing the server binaries alone does not complete the fix: you must also rebuild extensions written in C.
The issue affects versions earlier than 18.7, 17.12, 16.16, 15.20, and 14.25, depending on the branch. PostgreSQL has not reported attacks exploiting CVE-2026-6460; that does not remove the need to apply the update. The specific ability to create objects depends on the account's permissions, and it is unclear whether default privileges are sufficient to reach code execution.
«trigger this crash as a lowest-privileged login role»
— Mehmet Ince, security researcher
1. Identify the version and installation type
Start by finding out which version each instance is running, not just the one installed on your machine. IlSoftware.it says you can check the version from an SQL session with:
SELECT version();Compare the major branch returned by the query with the table and note which servers need updating. If PostgreSQL comes from a Linux distribution's repositories, IlSoftware.it also recommends checking the provider's advisories: it may incorporate a fix into its package without changing the version number you expect to see.
| Affected branch | Fixed version |
|---|---|
| 18 | 18.7 |
| 17 | 17.12 |
| 16 | 16.16 |
| 15 | 15.20 |
| 14 | 14.25 |
The table lists the fixed versions released by the PostgreSQL Global Development Group. PostgreSQL 14.25 is the final release in that branch; PostgreSQL 14 has reached the end of its life cycle. If you are still on that branch, apply the latest available update and plan a migration to a supported version.
2. Update the server to the release for your branch
Install the corresponding fixed version: you do not need to switch major branches to address this advisory. The PostgreSQL 18.7 release notes say that users updating within the 18 series do not need to dump and restore the database. Do not apply that guidance to a migration between branches: it refers to performing a minor update within 18.x.
If the server runs outside its package's service unit—for example, under Patroni—a maintainer of the RPM packages recommends restarting it immediately after the update. Check how each instance is managed and confirm that the process is running the new binaries; do not assume that installing the package is enough.
3. Rebuild extensions written in C
This task is part of fixing CVE-2026-6460. PostgreSQL added checks to detect composite values whose type no longer matches the expected type, but complete protection requires rebuilding C-language extensions against the updated version. Some also need changes to their source code.
Update or recompile all installed C extensions, and check that the packages available for your system have been rebuilt. If you manage the build yourself, follow each extension's instructions and test that it loads again on the updated server. The rebuilt version may not load on older servers, so coordinate both changes.
4. Update client tools
The server is not the only component affected by the advisories. The Hacker News notes risks in client utilities: a manipulated backup file could cause pg_restore to execute code with the permissions of the user who runs it; a compromised source server could cause psql to execute code through a restore script included in a pg_dump tar output.
Update pg_dump, pg_restore, reindexdb, and vacuumdb on every machine that uses them. Include administration servers, workstations, and automation systems. Do not restore from untrusted files, and do not assume that updating the engine automatically updates tools installed on other machines.
5. Review indexes and backups
The PostgreSQL 18.7 release notes warn of several bugs that can corrupt indexes and recommend examining changelog entries that mention REINDEX. Identify which indexes in your installation may be affected and rebuild those, following the instructions in the relevant release notes; do not turn the review into an indiscriminate rebuild of every index.
If you use incremental backups, consider existing ones untrustworthy: the notes say they may have been corrupted. After updating, create a new full backup and use it as the base for subsequent incremental backups. Do not continue chaining incremental backups on top of a pre-update base.
6. Confirm the status of cloud instances
Mehmet Ince privately shared proof-of-concept exploits with security teams at several providers, including AWS, Microsoft, Google, Supabase, Databricks, and Ubicloud. The services mentioned include Aurora and RDS, Azure PostgreSQL, and AlloyDB. The current patch status of each service was not specified.
If you use managed PostgreSQL, check with your provider whether the instance has received the fix and what action you need to take. Do not assume that all services were updated at the same time, or try to apply the steps for a self-managed server yourself if the provider manages the engine.
Mistakes to avoid
Do not disable composite_type_mismatch to work around compatibility problems. PostgreSQL warns that disabling these checks carries security risks; some extensions may need code changes precisely to work with the protection enabled.
Also, do not treat a firewall or the absence of known attacks as a substitute for patching. According to the project's advisory, CVE-2026-6460 requires an account capable of creating objects, not a superuser account. Updating is the primary measure; reviewing unnecessary permissions can reduce exposure, but it is not a replacement.
Finally, do not forget the components left out of the server update process: C extensions, client utilities, potentially affected indexes, and the base for incremental backups. And if you are still running PostgreSQL 14, remember that 14.25 closes that branch: the fix does not extend its support.
Sources: The Hacker News, IlSoftware.it, VONNG, PostgreSQL Global Development Group, PostgreSQL Global Development Group
