PostgreSQL patches 52 flaws, including CVE-2026-6460 RCE

PostgreSQL shipped security updates on November 12 that fix 52 flaws. The headline bug, CVE-2026-6460, is a type confusion flaw that lets a database user who can create objects run code as the operating system user running PostgreSQL. No attacks have been reported. Patch, and rebuild your C extensions while you’re at it.

What to do first

Per The Hacker News:

1. Update the server to 18.7, 17.12, 16.16, 15.20 or 14.25, matching your major version. Everything before those releases is affected.
2. Rebuild or update every C-language extension at the same time as the server. Extensions built against older releases still load, but they “may not be protected from the vulnerabilities fixed in this release,” according to a notice from the project’s RPM package maintainers. Some extensions need source changes.
3. Expect friction. Extensions rebuilt for the new releases can fail to load on older servers, and extension packages in the project’s RPM repositories now require the new minor release.

Patching the server alone is not full protection. That is the part people will skip.

What the flaw is

CVE-2026-6460 involves composite types, which are types built from named fields. A field’s type can change while older values of that type are still held elsewhere in the server, so the server can read an old value as if it had the new type. The fix adds version checks so the server can detect a value that no longer matches its type. The reported CVSS score is 8.8.

Exploitation status

• The PostgreSQL Global Development Group has not reported attacks. CISA’s assessment in the CVE record lists exploitation as none.
• Researcher Mehmet Ince published a technical writeup this week describing a working exploit against PostgreSQL 18.6. The coverage says the writeup stops short of the final step that runs a command. We are not describing the method here.
• Ince also privately shared proofs of concept in August with security teams at managed PostgreSQL providers, including AWS (Aurora and RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks and Ubicloud. The writeup does not give each service’s current patch status, so check your provider’s own notices.

Who can pull it off

This is the unclear part. The project’s advisory describes the attacker only as someone who can create objects, and Red Hat says a login with the ability to create or modify objects is needed. Ince wrote that he could trigger the crash as a lowest-privileged login role. None of the sources says whether a default-privilege account can go beyond the crash to code execution. Until that is settled, treat any account with create rights as in scope, and prioritize multi-tenant and shared databases.

Other fixes worth knowing

• The project rates 32 of the 52 flaws at 8.8, the highest score in the release.
• Only one server flaw needs neither a login nor user action: CVE-2026-116322, which lets an unauthenticated client trigger a restart of PostgreSQL 18 servers. If you run 18.x and the database faces untrusted networks, that is your second priority.
• Client tools are affected too. A crafted archive can make pg_restore run code as the user running it, and a compromised source server can make psql run code through the restore script in pg_dump’s tar output. Don’t restore archives you don’t trust, and update admin workstations and backup hosts.

Priority call

Internet-reachable or multi-tenant PostgreSQL first, then anything where untrusted users hold create rights, then client tooling. Deprioritize single-tenant databases where only trusted administrators can log in, but still schedule the extension rebuilds.