It's that time again. Postgres v18.4 release (along with 17.10, 16.14, 15.18, 14.23) has dropped some serious hints in the git logs, and it's bringing a significant payload of CVE tagged patches. As a seasoned Postgres end-user and an erstwhile DBA, whenever I see a flurry of high-vulnerability security commits, I immediately start recommending that customers begin planning their patching cycles.
Note: Some official CVSS scores are as high as 8.8! and so the urgency and relevance should be considered when prioritizing this upgrade.
Tom Lane: Last-minute updates for release notes.
Security: CVE-2026-6472, CVE-2026-6473, CVE-2026-6474, CVE-2026-6475, CVE-2026-6476, CVE-2026-6477, CVE-2026-6478, CVE-2026-6479, CVE-2026-6575, CVE-2026-6637, CVE-2026-6638
Let's quickly take a quick look at the CVE list:
The Memory and Overflow Fixes
- CVE-2026-6472 - Git commit (CVSS Score: 5.4) — Missing CREATE Privilege Check on Multirange Types. (Backpatched to: 14, 15, 16, 17, 18)
- CVE-2026-6473 - Git commit (CVSS Score: 8.8) — The Memory Overflow Ghost. (Backpatched to: 14, 15, 16, 17, 18)
- CVE-2026-6474 - Git
commit
(CVSS Score: 4.3) — Unsafe
pg_strftime()handling. (Backpatched to: 14, 15, 16, 17, 18) - CVE-2026-6477 - Git commit (CVSS Score: 8.8) — Frontend Large Object Buffer Overruns. (Backpatched to: 14, 15, 16, 17, 18)
The Replication and Backup Vulnerabilities
- CVE-2026-6475 - Git
commit
(CVSS Score: 8.8) — Path Traversal in
pg_basebackup&pg_rewind. (Backpatched to: 14, 15, 16, 17, 18) - CVE-2026-6476 - Git
commit
(CVSS Score: 7.2) — SQL Injection in
pg_createsubscriber. (Backpatched to: 17, 18 —pg_createsubscriberwas introduced in v17) - CVE-2026-6638 - Git commit (CVSS Score: 3.7) — SQL Injection in Logical Replication. (Backpatched to: 16, 17, 18)
The Cryptography and DoS Defenses
- CVE-2026-6478 - Git commit (CVSS Score: 6.5) — Defeating Timing Attacks in Auth. (Backpatched to: 14, 15, 16, 17, 18)
- CVE-2026-6479 - Git commit (CVSS Score: 7.5) — SSL/GSS Recursion Denial of Service (DoS). (Backpatched to: 14, 15, 16, 17, 18)
The Edge Cases: Catalogs and Contrib Modules
- CVE-2026-6575 - Git commit (CVSS Score: 4.3) — Statistics Restore Crashes. (Backpatched to: 18 only)
- CVE-2026-6637 - Git
commit
(CSS Score: 8.8) —
refintContrib Vulnerability. (Backpatched to: 14, 15, 16, 17, 18)
The Data Anomalies: Breaching the Trend Line
Stepping back and looking at the historical data for Postgres security releases, there's a distinct pattern in how deeply CVEs are backpatched. Typically, the volume of fixes applied to older, mature branches remains relatively low and stable. However, as the graph below illustrates, this release cycle has completely shattered that historical trend line.
The "Vulnerability Age Points" metric works as follows: for each CVE fixed in a given month, I calculate the age of the oldest major version that received the backpatch (e.g., a fix backpatched to v14 in 2026 scores 5 points, since v14 was released in 2021). The column then sums these scores across all CVEs in that month. This captures both the depth (how far back) and the breadth (how many CVEs) of backpatching activity in a single number.
While it's worth acknowledging that this metric has a natural mathematical bias—since a high volume of CVEs automatically inflates the score (e.g., 11 CVEs all scoring 5 points mathematically guarantees a score of 55)—it still accurately visualizes a very real spike in activity. For years, this metric hovered in the single digits, occasionally bumping up during a busy quarter. But recently, the scores have slowly grown and ballooned for the upcoming May 2026 release.
This isn't just backpatching one or two obscure bugs to a 5-year-old release; it's a highly elevated volume of CVEs all the way back to the oldest supported versions. The sheer depth and breadth of these fixes indicate a fundamental shift in how vulnerabilities are being discovered.
A Personal Hunch: Could AI Be Behind the Spike?
Update: - Feels good to be right :) . This post was written before the release and then it is good to guess correctly that many of these CVEs were found by multiple different AI tools. See CVE pages linked to read more.I want to be upfront: I have zero insider knowledge here, and no data to back this up. But looking at the sheer
volume and the deeply obscure nature of these fixes—integer overflows in palloc_array() edge cases,
subtle recursion bugs in startup packet handling, timing side-channels in auth paths—it's hard not to wonder
whether some of these discoveries were aided by AI-driven code auditing tools.
Projects like Anthropic's Glasswing are designed to autonomously analyze large codebases for exactly these kinds of subtle, hard-to-spot vulnerabilities. This hunch is further supported by broader industry shifts; recently, trusted figures like Linux kernel maintainer Greg Kroah-Hartman publicly acknowledged that AI bug reports have evolved from "slop" to genuinely high-quality submissions.
The pattern of findings here—broad, systematic, reaching deep into mature code—feels different from the typical "researcher finds one clever exploit" pattern. It feels more like a methodical, machine-assisted sweep. But again, that's purely a hunch on my part, and I'd be happy to be corrected.
Final Thoughts
With the release announcement just around the corner, these fixes are being backpatched to earlier supported versions. As the per-CVE annotations above show, most of these CVEs affect all currently supported versions (14 through 18), though a few are scoped to newer releases only (CVE-2026-6476 to v17+, CVE-2026-6638 to v16+, and CVE-2026-6575 to v18 only).
What does this mean practically? Since these are all minor version upgrades, no full
pg_upgrade is needed. Usually, you can simply stop Postgres, install the updated binaries for your
version, and restart. However, always carefully read the release notes before upgrading! Patches involving
catalog objects or extensions (like the refint fix) might require DBAs to run specific SQL commands
post-upgrade, such as ALTER EXTENSION ... UPDATE. The risk of not patching here
significantly outweighs the risk of the upgrade itself.
If you expose Postgres to untrusted clients, or operate in a multi-tenant environment, the authentication DoS (CVE-2026-6479) and backup path traversal (CVE-2026-6475) should put this upgrade high on your priority list.
For the latest official information, check the Postgres Security Page and the Minor Release Roadmap.
Stay safe, and happy patching.

No comments:
Post a Comment