PostgreSQL's Biggest Security Release Ever: 28 CVEs, and What to Actually Worry About

PostgreSQL shipped its largest security release ever on August 13: 28 CVEs fixed in one batch, across every currently supported version, plus PostgreSQL 19’s third beta. Seventeen of those 28 carry a CVSS score of 8.0 or higher. Nine have “executes arbitrary code” in the title. If you run Postgres anywhere in production, this is worth ten minutes of your attention, but not the kind of panic the raw numbers might suggest. Almost all of the serious bugs share the same precondition, and understanding it is what tells you whether this is an emergency or a scheduled patch window.

The headline number, and the nuance that matters

28 CVEs in one release is a genuinely unusual volume for PostgreSQL, a project with a strong track record on security discipline. But CVE count alone doesn’t tell you about exploitability, and the pattern across the most severe bugs here is consistent: they’re heap buffer overflows triggered by a crafted SQL query, not by an unauthenticated network request.

CVE	Component	CVSS	Trigger
CVE-2026-14664	regexp	High	Text that fails encoding validation
CVE-2026-14669	to_char(timestamptz)	High	A long POSIX timezone abbreviation
CVE-2026-14670	plperl	High	A crafted function returning a tied hash
CVE-2026-14676	pg_stat_statements	High	Crafted queries containing array constants
CVE-2026-14662	tsvector/tsquery	8.8	Integer wraparound in size allocation
CVE-2026-6471	Logical decoding	7.2	dlopen of an arbitrary file
CVE-2026-6464	psql COPY FROM STDIN	8.1	Early COPY failure processes input as psql commands

Each of these needs someone, or something, able to issue a specific SQL query, define a function, or feed input to a client tool. That’s a meaningfully different threat model than “anyone on the internet can hit port 5432 and own your database.” It’s the same category of risk as a SQL injection vulnerability in your application layer: the database isn’t the weak point on its own, but a weak point upstream (an injectable query, an untrusted stored procedure author, a multi-tenant setup where tenants can run arbitrary SQL) turns these bugs from theoretical into exploitable.

Who’s actually exposed

Three profiles should treat this release as urgent rather than routine:

Multi-tenant databases where tenants run their own queries. If your product lets customers write SQL, custom reporting, embedded analytics, a query builder, an untrusted tenant is exactly the “query author” these CVEs assume. A tenant boundary that relied on PostgreSQL’s own query execution being safe just got weaker until you patch.

Applications with any SQL injection surface. These bugs turn an ordinary injection point into a code execution primitive instead of just a data leak. If you’ve been treating a known or suspected injection issue as lower priority because “worst case they read some data,” this release changes that calculus.

Anyone running pg_stat_statements, which is extremely common, it’s a standard extension for query performance monitoring, and CVE-2026-14676 puts a heap overflow directly in its query-normalization path.

If your Postgres instance only ever executes a fixed, parameterized query set from a trusted application, with no ad hoc SQL, no untrusted function authors, and no SQL injection surface, your actual exposure is lower. It’s still worth patching on the normal cadence; “lower exposure” isn’t “no exposure,” and the logical decoding bug (CVE-2026-6471, arbitrary dlopen) has a different trigger path worth checking against your own replication setup specifically.

What to run

The fix is a point-release update, not a major-version migration, on whichever line you’re already running:

18.x -> 18.6
17.x -> 17.11
16.x -> 16.15
15.x -> 15.19
14.x -> 14.24

Check your current version with SELECT version();, match it against the table, and schedule the update through your normal patch process. There’s no configuration workaround that closes these specific bugs; restricting who can execute arbitrary SQL, tightening pg_hba.conf, revoking unnecessary function-creation privileges, reduces the population of people who could trigger them, but the actual fix requires the binary update. If you’re mid-decision on whether PostgreSQL 18 is worth the upgrade already, or tracking what’s landed so far in 19’s beta cycle, this release doesn’t change either calculus, it’s orthogonal to the major-version question. Patch your current line first, then make the version decision on its own timeline.

The PostgreSQL 14 clock

Buried in this release is a separate, unrelated deadline: PostgreSQL 14 goes end of life on November 12, 2026, and 14.24 is one of the last scheduled fix windows before that cutoff. If you’re still running 14 in production, that’s not an August problem, it’s a now problem for planning purposes. A major version upgrade takes real lead time, testing, a migration window, rollback planning, and “we’ll deal with it before November” gets tighter every week you wait. Treat this release as the trigger to put that upgrade on the calendar if it isn’t already.

None of this is a reason to distrust PostgreSQL’s security process. A large, coordinated batch fix across every supported line, released together with clear CVSS scoring and precise trigger conditions per bug, is what a mature security response looks like. The number 28 is the headline. The trigger condition on almost every serious one of them is the number that should actually shape your response.