PostgreSQL’s 52-Flaw Security Release at a Glance: The 22-Year-Old Bug, Who Is Exposed, and an Update Checklist

The PostgreSQL project released a security update on Thursday that fixes 52 vulnerabilities in the open-source database, which many line-of-business apps, websites and cloud services rely on behind the scenes. The most serious bug can let a logged-in database user run commands on the server. Fully closing it takes more than just installing new binaries. Here is the release in reference form.

The facts below come from The Hacker News’ breakdown of the PostgreSQL release, which draws on the project’s advisory, its release notes and the researcher’s write-up.

Fact sheet: the headline flaw

• ID and score: CVE-2026-6460, CVSS 8.8.
• Type: type confusion involving composite types (types made of named fields). A field’s type can be changed while older values of that type still live elsewhere in the server, so the server may read an old value as if it had the new type.
• Impact: code execution with the rights of the operating-system account that runs PostgreSQL.
• Who can trigger it: the project’s advisory says someone who can create objects. Red Hat’s assessment says a database login with the ability to create or modify objects. The researcher says he could cause a crash as the lowest-privileged login role. No source says whether an account with only default privileges can go beyond the crash to running code.
• Affected: every version before 18.7, 17.12, 16.16, 15.20 and 14.25.
• Exploited? No attacks reported by the project, and CISA’s assessment in the CVE record lists exploitation as none.
• Age: researcher Mehmet Ince traces it to May 5, 2004, when PostgreSQL gained the ability to change a column’s type. His code-execution technique relies on a later change from May 14, 2015.
• Public exploit details: Ince’s write-up, demonstrated on 18.6, includes SQL that crashes an unpatched server and a second step that leaks memory addresses, but leaves out the final command-execution step.
• Cloud services: Ince privately shared proofs of concept in August with AWS (Aurora and RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks and Ubicloud. Each provider’s current patch status is not given.

Fact sheet: the rest of the release

• 52 flaws in total, with 32 of them rated 8.8, the highest score in the release.
• Only one server flaw needs neither a login nor any user action: CVE-2026-116322, which lets an unauthenticated client force PostgreSQL 18 servers to restart.
• 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 via the restore script in pg_dump’s tar output.
• PostgreSQL 14 has reached end of life. 14.25 is its last release, and older major versions are affected but received no fix.
• No workaround is offered for servers that cannot be updated yet.

Update checklist

1. Install the minor release that matches your major version: 18.7, 17.12, 16.16, 15.20 or 14.25.
2. Rebuild or update every C-language extension at the same time. Per the project’s RPM maintainers, extensions built against older releases still load but may not be protected, and some need source changes. Rebuilt extensions may fail to load on older servers.
3. If PostgreSQL runs outside its package’s own service unit (for example under Patroni), restart it right after updating.
4. Update client tools such as pg_dump, pg_restore, reindexdb and vacuumdb on every machine that runs them, not just the database server.
5. Leave the new composite_type_mismatch setting alone. Turning off the checks carries security risks, according to the project.
6. Follow the reindexing steps in the release announcement.
7. If you use incremental backups, take a fresh full backup and base later incrementals on it.
8. If you are on 14 or older, plan a major-version upgrade.

What this means for your company

You may run PostgreSQL without knowing it. It often sits underneath accounting, ERP, inventory, ticketing and web applications, either on your own servers or inside a vendor’s hosted service. Start by asking a simple question: where do we have it? Then:

• Ask your software vendors and hosting providers whether they use PostgreSQL and when they will apply this release.
• For databases you run, schedule the update and the extension rebuild together, and test restores afterward.
• Review which database accounts can create or change objects. Application and reporting accounts usually do not need that right.
• Do not expose database ports to the internet. Limit connections to the systems that need them.
• Treat machines that run backup and restore tools as part of the patch scope.

If you need help finding where PostgreSQL runs in your environment and getting this release in safely, we are glad to help. Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.

About The Author

L7 News

See author's posts