- PostgreSQL's maintainers fixed 52 security flaws, including CVE-2026-6460, which a researcher traces to a 2004 change. The project has reported no attacks using it.
- Per The Hacker News, closing CVE-2026-6460 also means rebuilding C-language extensions. Reindexing and a new backup are conditional steps for other fixes in the same release.
- Leaders should ask who holds object-creation rights on their databases. PostgreSQL 14's end of life is a separate issue that calls for its own upgrade plan.
A flaw whose root a researcher traces to 2004
Some software risk is not new. It can sit in a design decision made long ago and wait for someone to look hard enough. This month's PostgreSQL release shows how that can look.
The PostgreSQL project shipped patch releases for every supported branch, from 14.25 up to 18.7, plus a second release candidate for version 19. The project says the update closes 52 security vulnerabilities and more than 140 other bugs.
The project scores one of them, CVE-2026-6460, at 8.8 on the CVSS severity scale. According to The Hacker News, a database user who can create objects could use it to run code on the server. Whatever runs would have the same rights as the operating system account that PostgreSQL itself runs under.
How the flaw works
PostgreSQL has a feature called a composite type. Think of it as a record with labelled fields, where each field holds its own kind of data. The kind of data in one field can be changed later.
The trouble is that older copies of such a record may still sit in other parts of the server. A stale copy can then be misread under the field's new type. This is called type confusion: the software treats data as one thing when it is another.
The project's fix adds version checks. These let the server notice when a stored record no longer fits the type it claims to have.
Researcher Mehmet Ince published a technical writeup this week. He traces the root to a May 5, 2004 change that let PostgreSQL alter a column's type. His route to code execution depends on a later change, made on May 14, 2015. That means the exploitable path he describes is about 11 years old, not 22.
The writeup gives SQL for a crash and for a follow-on step that exposes memory addresses. It withholds the last step, the one that makes the server run a command.
How much is known about the risk
The project has not reported attacks that use the flaw. The Hacker News adds that the CISA entry in the CVE record also rates exploitation as none.
An attacker needs a database login. Red Hat says that login must be able to create or modify objects. Ince wrote that he could trigger the crash as a "lowest-privileged login role". The project's advisory does not say which privileges are needed.
One question stays open. None of these sources states whether an account with only default privileges could go past the crash to code execution. Treat that as unanswered, not as reassurance.
This is the lesson for leaders. "Authenticated" sounds like a comfort, but it only moves the question. Every application, contractor and reporting tool with a database login is part of the exposure. The patch tells you which flaw to close. It does not tell you who holds those logins.
What the update asks of you
For this flaw, The Hacker News names one extra step. Any C-language extensions need to be rebuilt or updated at the same time as the server. Extensions are add-on code that loads into the database. The outlet says builds made against older releases still load, but may not be protected.
The release announcement lists other follow-up work. It ties that work to different bug fixes, not to CVE-2026-6460. Each item applies only in certain cases.
The project says to reindex a GIN index if you suspect it was hit by the corruption fixes. Reindexing means rebuilding an index. Other cases are also named: pg_trgm users, anyone who has seen "missing chunk number" errors, and anyone with B-tree indexes on columns declared as bpchar without a length. Teams that use incremental backups are advised to take a new full backup. None of this is required of everyone, and no dump and reload is needed.
Managed services add a dependency. Ince says he privately shared proofs of concept with security teams in August. The services he worked with were AWS's Aurora and RDS, Azure PostgreSQL, Google's AlloyDB, Supabase, Databricks and Ubicloud. The writeup is silent on where each provider stands on patching. It is reasonable to ask your provider directly.
A separate issue: PostgreSQL 14 has ended
With this release, the project retires PostgreSQL 14. The version is now end of life and gets no further security or bug fixes. This is unrelated to CVE-2026-6460, but it matters for the same reason. Any production system still on 14 needs an upgrade plan.
The project plans general availability of PostgreSQL 19 for November 19, 2026. That date is a natural moment to review upgrade plans.
Questions to put to your team
Ask which PostgreSQL versions run in production, and whether any are still on 14. Ask which accounts can create or modify objects, and whether each one needs to. Ask for a list of C-language extensions and who owns rebuilding them.
Ask each managed database provider for its patch status on CVE-2026-6460. Then have the team check the release's reindex and backup conditions against your systems, and do only the steps that apply.
A database patch is a checklist, not a single click. A flaw with roots in a 2004 change is not closed until the items that apply to you are done.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: PostgreSQL Global Development Group.
