PostgreSQL closed 28 CVEs at once: what should your patch latency be

On August 13, 2026, PostgreSQL published the largest security release in its history: 28 CVEs fixed in a single day. The previous record was 11. The number itself is less alarming than the metric Umair Shahid, writing on the Stormatics blog (Planet PostgreSQL), puts at the center of the discussion: how long your operation takes between a fix being published and that fix actually running in production. He calls this patch latency, and it's the variable the DBA actually controls.

The Number Went Up Because Attention Went Up

The panicked reading is that the code got worse. The correct reading is the opposite. In all of 2025, 7 CVEs were fixed; in 2026, there are already 44, of which 28 came in this single release. The jump comes from more people and better tools looking at the code. Some of the bugs were reported by security teams that use AI, including OpenAI's, and their nature gives away the origin: buffer overflows, integer wraparounds, type confusion. These are classic memory-safety bugs, exactly the kind automated fuzzing finds well, and AI is making fuzzing much more effective.

Browsers and operating system kernels went through this level of scrutiny years ago. Postgres is going through it now. Every bug found and fixed is one less bug an attacker can use later. The code didn't get worse; it got more examined, and much of these flaws had been dormant in stable code for years.

Why the Window Is the Risk

A CVE is a public document. It names the bug, lists the affected versions, and often provides enough detail to build an exploit. One of August's bugs, a remote code execution flaw in to_char(), already has a working proof of concept published, and a national cybersecurity center issued a "patch immediately" advisory. The same AI that helps the defender find the flaw helps the attacker turn it into a working exploit, and the interval between "CVE published" and "someone scanning your servers with it" only keeps shrinking.

Shahid points to the 2025 precedent: CVE-2025-1094, a SQL injection hidden inside Postgres's own string-escaping functions, appeared as part of a real attack chain against production systems. The bug had been in stable code for years. It only started to matter once it went public and someone motivated picked it up. In his words, an unpatched, already-disclosed CVE is "a known door with the break-in instructions printed right next to it".

The Good News: Applying a Minor Release Is Cheap

Here Postgres makes life easier. Minor releases (18.4 to 18.6, 17.10 to 17.11) are cumulative and binary-compatible. There's no dump and reload, no pg_upgrade. You stop the server, swap the binaries, and start it back up. On a single node, this takes seconds.

If the swap takes seconds, why do teams take weeks? Because the swap was never the expensive part. Testing is. Scheduling is. Doing it without dropping live connections is. A patch SLA turns all of that from a scramble into routine.

The SLA here is simply a promise the team makes to itself about response speed, ordered by bug severity. The suggested model:

• Remote code execution, or an existing public exploit: patch within days. This month's release is the clear example.
• High severity, no known exploit yet: patch within one to two weeks.
• Everything else: goes into the next scheduled maintenance window.

The exact numbers are each operation's own choice. The point is to decide them before the CVE arrives. When a release like the one on August 13 appears, everyone already knows it's a "within days" event, and nobody debates it in a chat thread while the clock runs.

How to Hit the Window Without Breaking Anything

Three habits make a tight SLA safe to keep:

Patch the standby first. Apply the update to a replica, observe its behavior, fail over, and only then patch the old primary. Done well, the user sees a brief blip instead of an outage. It's the same standby-first discipline used in rolling upgrades of Patroni clusters.

Test in staging and read the "Updating" section. Most releases are a clean binary swap, but some call for an extra step, and this one did. Anyone using GIN indexes needs to check whether reltuples values remain sane. Anyone using btree_gist on float or bit columns, or ltree with very long paths, may need a reindex. Two minutes of reading save an afternoon of confusion.

Keep a restore you've actually tested. Patching and recovery use the same muscle. When your backup restores cleanly and you know your real recovery time, patching stops feeling risky, because there's always a way back. If you haven't run a restore drill recently, do it before the next patch, not after.

What Isn't the Server Binary

The server binary is the obvious target, but it's not the whole job. Client libraries and extensions also get CVEs. In November 2025, libpq received a fix for an integer wraparound (CVE-2025-12818) that lived in the client library, not the server. August's batch touched pgcrypto, pg_stat_statements, and PL/Perl. Anyone pinning driver versions, running a connection pooler, or depending on contrib modules needs to count all of this into patch latency. A fully patched server talking to an old libpq is only halfway there.

Running an Unsupported Version Is Also Patch Latency

There's a guaranteed way to make your patch latency infinite: run a version that no longer receives fixes. PostgreSQL 14 gets its last round of fixes on November 12, 2026. All 28 of August's CVEs were fixed in 14.24, so there's still time to apply this round and plan the migration to a supported major version. After that date, any new bug found in 14 stays open permanently. Patch cadence and version currency are the same discipline wearing two hats.

What to Do This Week

Shahid's practical summary: apply 18.6, 17.11, 16.15, 15.19, or 14.24 in production; patch the standby first and fail over; read the "Updating" notes before starting; and write your severity tiers so the next CVE doesn't turn into a debate. For Brazilian operations that struggle with short windows and tight SLAs, the central message is sober and correct: data security doesn't come from post-incident scrambling, but from criteria decided in cold blood, a disciplined standby, and a restore you know works.