PostgreSQL fixes a 22-year-old bug that lets database users run code on the server

The PostgreSQL project released updates 18.7, 17.12, 16.16, 15.20 and 14.25 on November 12. According to the project, they fix 52 security vulnerabilities and more than 140 other bugs. The most discussed is CVE-2026-6460, rated 8.8 out of 10: a database user who is allowed to create objects can run their own code on the server with the rights of the operating system user that runs PostgreSQL. The project gave the same score to 31 other flaws in this release. No attacks using CVE-2026-6460 have been reported.

Why the bug is 22 years old

The flaw involves composite types, which are types built from several named fields. A field's type can be changed while older values are still held in other parts of the server, and the server then reads an old value as if it already had the new type. In its advisory, the project admits the system had inadequate tracking of typed values. Researcher Mehmet Ince, who demonstrated a working exploit on version 18.6, traces the problem back to May 5, 2004, when PostgreSQL gained the ability to change a column's type, The Hacker News reports.

Ince says he could crash an unpatched server with the lowest-privileged login role. None of the sources says whether such an account can go on to run code. In August he adapted the exploit for managed databases and shared it with the security teams of AWS, Microsoft Azure, Google, Supabase, Databricks and Ubicloud. Whether each of them has patched is not reported.

Who should worry

Mostly anyone who lets other people into the same database: hosting companies, cloud services and any project that gives customers their own PostgreSQL account. If only your own application talks to your database, an outside attacker would first need to get rights inside it. Client tools were fixed too: a crafted archive can make pg_restore run code on the machine of whoever restores it. Only one of the 52 flaws works without logging in, and it lets an attacker restart a PostgreSQL 18 server.

It is not the only server update this week worth installing without delay: we recently covered an HTTP/2 flaw in Apache.

What to do

• Update the server to 18.7, 17.12, 16.16, 15.20 or 14.25, matching your major version. No dump and reload is needed.
• Rebuild or update every C-language extension at the same time. Old builds still load, but the RPM package maintainers say they may not be protected.
• Update pg_dump, pg_restore, reindexdb and vacuumdb on every machine that runs them.
• If PostgreSQL runs outside its package's service unit, for example under Patroni, restart it right after updating.
• Do not turn off the new checks with the composite_type_mismatch setting: the project warns this is a security risk.
• Follow the "Updating" steps in the release announcement: reindex affected indexes (GIN, pg_trgm GiST, B-tree on bpchar columns), and take a new full backup if you use incremental backups.
• If you are on version 14 or earlier, plan an upgrade: there will be no fixes after 14.25.