PostgreSQL Ships Emergency Patch for 11 CVEs Across All Versions

Every long-running database is a bit like an old terraced house in Dublin. The front rooms get repainted every year, but the wiring behind the skirting boards has been there since the seventies, and nobody really wants to look at it. On May 14, the PostgreSQL maintainers pulled up the floorboards in the refint contrib module and found something nasty.

The emergency release covers every supported major version at once. That alone tells you the shape of what they found.

What Happened

PostgreSQL released emergency security updates on May 14, 2026, patching versions 18.4, 17.10, 16.14, 15.18, and 14.23. As Cyber Press reported, the coordinated release addresses 11 CVEs spanning stack buffer overflows, SQL injection, memory disclosure, and denial-of-service bugs, with more than 60 additional fixes bundled in for good measure.

The headline flaw is CVE-2026-6637, sitting at CVSS 8.8. It lives in the refint contrib module, an old piece of furniture that ships with Postgres and provides referential integrity triggers. A remote, unprivileged database user can supply crafted input to trigger a stack-based buffer overflow and execute arbitrary code as the OS user running the database server. That's the worst kind of database bug: it doesn't stop at the database boundary, it walks out into the host.

There's a secondary vector on the same CVE that enables SQL injection when an application exposes a user-controlled column as a refint cascade primary key. So even if you've got refint hardened against the overflow, a careless schema design can still hand an attacker arbitrary SQL during primary key updates.

The other heavyweights: CVE-2026-6473, an integer wraparound across multiple server features that forces undersized memory allocations and out-of-bounds writes; CVE-2026-6477, a gets()-style flaw in libpq's large-object functions that lets a malicious server superuser overwrite stack memory in psql and pg_dump; and CVE-2026-6475, a symlink-following path traversal in pg_basebackup and pg_rewind that can overwrite files like /var/lib/postgres/.bashrc. All four affect versions 14 through 18.

Then there's CVE-2026-6478, the MD5 timing channel, which only bites legacy deployments still using md5 entries in pg_hba.conf after being upgraded from PostgreSQL 13 or earlier.

Technical Anatomy

Let's talk about the guts of it, because the refint bug is genuinely interesting from an engineering perspective. The refint module predates Postgres's modern foreign key implementation. It's a contrib module that's been sitting there for over two decades, used by applications that long ago wired up triggers for cascade-style referential integrity. Most teams forgot it exists. Attackers, apparently, did not.

A stack-based buffer overflow in a database engine is a particular kind of horror. The PostgreSQL backend process runs as the postgres OS user, which typically owns the data directory, the configuration files, and the WAL. Arbitrary code execution at that level isn't just a database compromise. It's the whole node. From there, you read every config secret on disk, you tamper with replication, you write to authorized_keys, you pick your route out.

CVE-2026-6477 is the inverse threat model, and it's the one that should make anyone running shared or multi-tenant Postgres infrastructure sit up. The flaw lets a malicious server superuser overwrite stack memory in the client tool. Anyone who has run pg_dump against a database they didn't personally provision knows the trust assumption baked into client tooling: you assume the server is benign. That assumption just broke. lo_read() is invoked by both psql and pg_dump, which means your nightly backup job is now a viable attack surface against the backup host.

CVE-2026-6475 follows the same pattern from a different angle. Symlink following during pg_basebackup plain-format runs or pg_rewind failover operations lets an origin superuser overwrite OS-level files on the replica. Hijack the .bashrc of the postgres OS account and you own the replica the next time anyone shells in.

The good news, per the PostgreSQL advisory, is that no database dump, reload, or pg_upgrade is needed. It's a binary swap and a service restart. The boring bit, not the part where it all falls over.

Who Gets Burned

Anyone running multi-tenant Postgres infrastructure, which in practice means most fintech, iGaming, and ad-tech platforms above a certain scale. If you operate a managed database product or you run logical replication across trust boundaries between business units, CVE-2026-6637 is your three-alarm fire. A low-privilege user in any tenant database with refint triggers configured can, in principle, escape to the host.

Payments platforms that still rely on legacy refint triggers from a Postgres 9.x or 10 migration are exposed twice. Once by the overflow, once by the cascade primary key SQL injection vector. I've seen plenty of payment ledgers where the cascade is wired into application-facing identifiers. That's the exact pattern this bug exploits.

iGaming operators running cross-region read replicas via pg_basebackup need to look hard at CVE-2026-6475. Failover during a regional incident is the worst possible moment to discover your replica's OS account got hijacked six hours ago.

The MD5 timing channel only matters if you've got md5 entries still living in pg_hba.conf. The default in all supported releases is scram-sha-256, which is unaffected. But legacy fintech deployments upgraded incrementally from version 13 or earlier almost always carry md5 entries forward because nobody wanted to force a password reset on every service account. That technical debt just got a CVE attached to it.

And then there's the calendar problem. PostgreSQL 14 reaches end-of-life on November 12, 2026. After that date, no further security fixes. Anyone still on 14 has roughly six months to plan a major version upgrade to 16 or 17. Treating this patch as the final 14.x security fix you'll ever apply is the right mental model.

Playbook for Engineering Teams

This week, in priority order:

Patch first, audit second. Push 18.4, 17.10, 16.14, 15.18, or 14.23 to every cluster. Binary swap and service restart, no dump-and-reload required. For Debian/Ubuntu: sudo apt update && sudo apt install postgresql-18. For RHEL/Fedora: sudo dnf update postgresql. For Homebrew on developer machines: brew upgrade postgresql@18. Managed cloud databases will follow the provider's maintenance window, but you can usually trigger a manual minor version upgrade from the console rather than waiting.

Once patched, grep your schemas for refint trigger usage. If you find any, audit which columns feed the cascade primary keys and whether any of them are user-controlled. That's your secondary SQL injection vector.

Audit pg_hba.conf across every host. Any line still using md5 needs to be migrated to scram-sha-256. Yes, this means rotating passwords for affected roles. Do it anyway.

Review your backup and failover infrastructure for the client-side risks. Anyone running pg_dump or pg_basebackup against databases owned by another trust boundary, including dev-against-prod debugging sessions, should treat the client host as compromised until patched.

If you're still on 14, set a calendar reminder for the November 12 deadline now and start the upgrade planning. PostgreSQL 16 or 17 are the realistic targets. Treat this patch as the start of that migration project, not the end of a quarter.

Key Takeaways

• PostgreSQL's May 14, 2026 release covers 11 CVEs across every supported major version (14 through 18), plus 60+ additional bug fixes.
• CVE-2026-6637 (CVSS 8.8) in the refint contrib module enables remote code execution as the OS user and a secondary SQL injection path via cascade primary keys.
• CVE-2026-6477 and CVE-2026-6475 flip the threat model: a malicious server can compromise client tools and replica hosts during routine pg_dump, pg_basebackup, or pg_rewind operations.
• Patching is a binary swap and service restart, no dump-and-reload required, so there's no excuse for sitting on this beyond a maintenance window.
• PostgreSQL 14 goes end-of-life November 12, 2026. Use this patch cycle as the kickoff for a 16 or 17 migration, not just a hotfix.

Back to the old terraced house. The wiring's been rewired this week, and the inspector's signed off. But the inspector is also reminding you that the lease on the whole building runs out in November. Patch the wiring, then start packing the boxes.