It’s a heap out-of-bounds write that an unprivileged role can reach over an ordinary database connection, with a plausible path to arbitrary code execution as the OS user running the backend. CVSS 8.8. Fixed in 18.4, 17.10, 16.14, 15.18, and 14.23, which shipped yesterday. If you maintain a PostgreSQL deployment, the upgrade window for this one is shorter than your usual maintenance cycle, and the threat model only requires a role that can run SQL.
The bug class
The advisory describes the vulnerability as an integer wraparound in multiple server features that causes the backend to undersize a memory allocation, after which a subsequent write goes off the end of the chunk. This is a textbook member of a class of bug PostgreSQL has been quietly fixing for years.
The pattern goes like this. The backend computes the size of a buffer from inputs — a row count, a string length, a width — multiplies or adds those together into a Size, and hands the result to palloc. If the arithmetic wraps around the 64-bit boundary (or, on a 32-bit build, the 32-bit boundary, but you are not running PostgreSQL on a 32-bit build in 2026, and if you are, that is a separate conversation), the resulting Size value is small. Sometimes very small. palloc happily returns a tiny chunk, the code goes on to write the full uncomputed amount into it, and you have heap corruption with attacker-controlled data and length.
PostgreSQL has hardening against the obvious version of this. MaxAllocSize is 1 GB minus one for ordinary palloc, and AllocSizeIsValid checks are scattered across the tree. Those checks catch the case where the result is implausibly large. They do not catch the case where the result was supposed to be implausibly large and arithmetic made it look small. That is the whole point of a wraparound bug: the safety net checks a value the attacker has arranged not to trip it.
Until the fix commits are public, the specific code paths are not worth speculating about in print. The bug class is worth understanding clearly, though, because it tells you something about the audit surface.
Why this one is bad
Three things.
First, the threat model is “any role with SQL access.” Not “any role that can CREATE EXTENSION pgcrypto,” not “any role that can load a function.” If you have an application user, that user can exploit this. Connection-pooled SaaS deployments where the application runs as a single role with broad object access are exactly in the strike zone.
Second, the exploit primitive is a heap out-of-bounds write, not a read. Read primitives leak; write primitives compromise. The advisory’s “arbitrary code execution as the OS user running the database” language is conservative — it is the worst case if the attacker controls enough of the write to land it where it matters. They do not always get there. They do get there often enough that you should not be the test case.
Third, this affects server features, not contrib extensions. The pgcrypto bugs Wiz disclosed earlier this month are unpleasant, but they are at least bounded by which deployments load pgcrypto. CVE-2026-6473 is bounded by which deployments run PostgreSQL.
What to do
Upgrade. The minor releases shipped yesterday and include the fix for this and ten other CVEs. There is no workaround, there is no GUC you can set, there is no extension you can remove. The patch is the mitigation.
If your deployment is on a managed provider, check what point release they are running. The major cloud Postgres services patched within hours of upstream in past cycles, but “within hours” is not “instantly,” and the cycle for this one is still in flight as I write this. RDS, Aurora, Cloud SQL, AlloyDB, Azure Database for PostgreSQL, Snowflake Postgres, Tiger Cloud, Neon, Lakebase — every one of these is patching this week, and a few of them have already done it. Verify, do not assume. SELECT version() and a glance at the minor number is thirty seconds of due diligence.
If you are running PostgreSQL 13 or older in production, this CVE is also a useful occasion to revisit that decision. PostgreSQL 13 went out of support last November and is not getting a fix.
The broader picture
Integer wraparound bugs in C code that allocates from variable-size inputs is one of the most boring vulnerability classes in the world. We have been finding them in long-lived C codebases for thirty years. They keep showing up in PostgreSQL not because the project is careless — the audit attention is, by software-industry standards, excellent — but because the surface area is large, the inputs are diverse, and the arithmetic is sometimes spread across four functions and a macro. The fact that this one was found and fixed is good. The fact that it took until 2026 to find it is the cost of having a 30-year codebase with that much SQL-reachable code.
Patch. Then go read the diff when it lands.