PostgreSQL CVE-2026-6460: database users who can create objects can run code on the server

What happened

On 12 November 2026 the PostgreSQL Global Development Group released PostgreSQL 18.7, 17.12, 16.16, 15.20 and 14.25. According to The Hacker News, these releases fix 52 security flaws. The most serious one is CVE-2026-6460 (CVSS 8.8), a type confusion flaw in the core server.

A database user who can create objects can use ALTER ... SET DATA TYPE to make the server read a stale value as if it had a new type. Other DDL statements can do the same, for example ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN. This lets the user run arbitrary code as the operating system user that runs PostgreSQL. The fix adds version checks so the server can detect values that no longer match their type.

Security researcher Mehmet Ince has published a technical writeup with a working exploit, which he demonstrated on PostgreSQL 18.6. The writeup includes the SQL that crashes an unpatched server and a step that leaks memory addresses. It does not include the final step that runs a command. He wrote that he could trigger the crash as a lowest-privileged login role. The sources do not say whether an account with only default privileges can go further and run code. Red Hat says an attacker needs a database login that can create or modify objects.

The PostgreSQL project has not reported any attacks using the flaw, and CISA does not list it as exploited.

The same releases fix other flaws, including CVE-2026-116322, which lets an unauthenticated client force PostgreSQL 18 servers to restart. They also fix flaws in client tools: a crafted archive can make pg_restore run code as the user who runs it, and a compromised source server can make psql run code through the restore script in pg_dump's tar output.

Who is affected

• PostgreSQL 18 before 18.7, 17 before 17.12, 16 before 16.16, 15 before 15.20 and 14 before 14.25.
• Older major versions are also affected and will not get an update. PostgreSQL 14 is now end of life, and 14.25 is its last release.
• The risk is highest on servers where people you do not fully trust have a database login that can create or change objects. This includes shared hosting, databases handed to customers and web applications whose database account owns its schema. If an attacker takes over such an application, for example through SQL injection, they may be able to use its database account in this way.
• Managed services: the researcher shared proofs of concept with AWS (RDS, Aurora), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks and Ubicloud. Their current patch status is not known. Check your provider's notices.
• Servers that do not run PostgreSQL are not affected. MySQL and MariaDB are not affected.

What to do now

1. Back up your PostgreSQL configuration (for example postgresql.conf and pg_hba.conf) and make sure you have a current database backup.
2. Update the server to the fixed release for your major version: 18.7, 17.12, 16.16, 15.20 or 14.25. If you use packages from your distribution (Debian, Ubuntu, RHEL and clones), install the fixed packages listed in your distribution's advisory as soon as they are available. Then use the package manager as usual (apt update && apt upgrade or dnf upgrade).
3. Update or rebuild every C-language extension at the same time as the server. The project's RPM maintainers warn that extensions built against older releases still load but may not be protected. Some extensions also need source code changes. Extension packages in the PostgreSQL RPM repositories now require the new minor release.
4. Restart PostgreSQL. If it runs outside its package's own service unit, for example under Patroni, restart it manually right after updating.
5. Follow the reindexing steps in the official release announcement. If you use incremental backups, take a new full backup and base future incremental backups on it.
6. Update client tools such as pg_dump, pg_restore, psql, reindexdb and vacuumdb on every machine that uses them, including backup hosts and admin workstations.
7. Do not use the new composite_type_mismatch setting to turn off the new checks. The project says doing so carries security risks.
8. If you cannot update right away, keep in mind that the project offers no workaround. Until you can update, review which accounts can create or change objects, especially accounts used by web applications or given to customers, and make sure PostgreSQL is not reachable from the internet unless it needs to be.
9. If you still run PostgreSQL 14 or an older version, plan an upgrade to a supported major version.

How to check whether you are affected

• Check the running server version with psql -c 'SELECT version();' or SHOW server_version;. Versions below 18.7, 17.12, 16.16, 15.20 or 14.25 within their major series are affected.
• Check the installed binaries and packages with postgres -V, dpkg -l | grep postgresql or rpm -qa | grep postgresql. Restart the server if the running version is older than the installed one.
• List installed extensions with SELECT extname, extversion FROM pg_extension; in each database. Make sure every C extension has been updated or rebuilt for the new release.
• Check the PostgreSQL logs for unexpected backend crashes, such as server processes terminated by a signal. The published exploit crashes unpatched servers, so crashes like these are worth a closer look.

Sources

• https://nvd.nist.gov/vuln/detail/CVE-2026-6460
• https://www.postgresql.org/support/security/CVE-2026-6460/