On August 13, the PostgreSQL project released security updates for all five supported branches on the same day, one fixed release each for 18, 17, 16, 15, and 14, covering 28 CVEs and over a hundred bugs in total. The heaviest of the batch is CVE-2026-14669, a heap buffer overflow in the to_char function, scored CVSS 8.8, with full technical details and exploit code already public.
The name to_char deserves a second look from any DBA. It is one of the most everyday functions in the database, formatting timestamps into strings, and it shows up all over reporting. The path it got broken through runs like this. POSIX-style timezone syntax lets users define custom timezone abbreviations, settable in a session with a single SET timezone statement. When to_char formats a timestamp, it copies the current timezone abbreviation into a fixed-size heap buffer, without checking the length first. An overlong abbreviation overflows the buffer, and the end result is arbitrary code execution as the operating system user running the database.
Unpack the CVSS vector and the attack conditions are clear. Network-reachable, low complexity, and low privileges required. Translated into DBA terms, any session that can connect and run SQL is enough. No superuser needed, since SET timezone is a session-level operation that ordinary users can perform anyway. In other words, for any database that has granted SQL execution to business teams or external users, this hole is wide open to them. Databases on a pure internal network, reachable only by application accounts, have a much smaller exposure, though it is hardly closed.
Among the 28 CVEs released the same day, five more sit at the same severity. A heap overflow in regexp that can bypass encoding checks, an overflow in pg_stat_statements triggered by array constants, a type confusion in pg_restore_attribute_stats, an integer wraparound in the levenshtein function of fuzzystrmatch, and an undersized memory allocation in tsvector. All six of these code-execution-grade bugs share one trait, each requires authentication first, a live session before anything fires. That common trait sets the risk ordering. Database cloud services, SaaS platforms, and PaaS offerings that grant tenants SQL access are environments where users are potential attackers to one another, and they must upgrade first. Standalone internal systems face real risk too, but the pace can drop a notch and slot into the regular maintenance window.
There is also a version-number detail you will run into during the upgrade. The official CVE page lists 18.5 as the fixed release for branch 18, but the actual release skipped that number. Regression testing turned up a problem, and the version jumped from 18.4 straight to 18.6. When writing version numbers into upgrade scripts, don’t copy from the CVE page. Go by the release announcement and target 18.6.
More pressing than any single vulnerability is the countdown on branch 14. Release 14.24 is the final round of maintenance for that branch, which reaches end of life in November 2026. After that, no patch will come, no matter how many holes surface. Of the 28 CVEs in this batch, every one that touches branch 14 got its last fix in 14.24. Plenty of production databases still run version 14 or older, for all kinds of reasons, application incompatibility, no headcount, forever deferred. Until November, those databases are on a running countdown with no cover. My suggestion is to use this incident as the opening and get the legacy upgrade project formally on the roadmap, at a priority above any tuning work or new-technology evaluation.
Looking back, PostgreSQL’s vulnerability density this year has indeed been high. Earlier came CVE-2026-6472, the missing privilege check in CREATE TYPE, and CVE-2026-6473, an integer wraparound. Now six more code-execution-grade issues in one release. Some read this as a sign that PG is being torn apart. I don’t see it that way. The explanation closer to the facts is that more people are using it, more people are scrutinizing it, and twenty years of buried C code is being dug up at an accelerating pace. Being found is bad news and good news at once, better than nobody looking at all. For DBAs this rhythm carries one plain implication, PostgreSQL’s quarterly security updates can no longer be skimmed away as email digests. They belong on the calendar, treated the same as Microsoft’s Patch Tuesday for SQL Server.
On the operational level, three things. Run SELECT version() across every instance and list the ones that don’t match. Upgrade the multi-tenant and externally exposed databases first, and queue the rest into the maintenance window. After upgrading, take a look at what this incident left untouched, whether session-level capabilities like timezone setting are genuinely needed by business accounts, and rein them in where you can. to_char is not going anywhere, and the reports still have to run tomorrow. But letting every session define its own timezone is something worth weighing again.
Sources
PostgreSQL official security advisory CVE-2026-14669 PostgreSQL release announcements for 18.6, 17.11, 16.15, 15.19, 14.24, and 19 Beta 3 ModB, “PostgreSQL Accelerates Its March, Five Branches Ship 28 CVEs Together”