PostgreSQL to_char Heap Buffer Overflow (CVE-2026-14669): What It Is and How to Read It Fast
CVE-2026-14669 is a CVSS 8.8 HIGH heap buffer overflow in PostgreSQL's to_char function that can run arbitrary code as the database OS user, patched August 13, 2026. Two questions decide your workload: is Postgres in your stack, and is your version older than 18.5 / 17.11 / 16.15 / 15.19 / 14.24?
PostgreSQL runs a large share of the world's application backends, so a heap buffer overflow that reaches arbitrary code execution in the core server belongs at the top of your review pile. CVE-2026-14669 is a CVSS 8.8 HIGH flaw in the to_char function, patched on August 13, 2026.
The score already tells you it is serious. The useful question is whether it reaches your environment, and how fast you can confirm that. Here is what the bug is, who is exposed, and how the VulnTracker CVE page answers "does this touch me?" in seconds.
What the vulnerability is
The bug lives in to_char(timestamptz). When PostgreSQL formats a timestamp with a time zone, a long POSIX timezone abbreviation can overflow a heap buffer. Whoever controls the timezone value can then run arbitrary code as the operating system user behind the database.
That is what drives the severity. Code runs as the OS account behind Postgres, which in many deployments is a direct path to the rest of the host, not just a database crash or a data leak.
The CVSS 3.0 vector says the same in shorthand: network attack vector, low complexity, low privileges required, no user interaction, and high impact to confidentiality, integrity, and availability. An attacker does not need admin rights, only a way to influence the timezone value, which in many applications sits closer to untrusted input than teams assume. The weakness class is CWE-122, heap-based buffer overflow.
Who is affected
Versions before PostgreSQL 18.5, 17.11, 16.15, 15.19, and 14.24 are affected. The fixes shipped together on August 13, 2026.
The exposure question is easy to state and easy to get wrong at scale: are you running any Postgres instance older than the fixed release for its major version? One old container image, one managed instance a release behind, or one forgotten reporting replica is enough to leave the door open.
Reading it on the VulnTracker CVE page
The VulnTracker page for CVE-2026-14669 gathers the details behind a patch decision into one view, instead of leaving you to stitch them together from the vendor advisory, NVD, and a couple of trackers.
The header shows the essentials at a glance: the 8.8 HIGH score, the product (PostgreSQL), the publication date, and a one-line summary of the flaw.
The Exploit Prediction (EPSS) section shows the current likelihood of exploitation in the wild, low at the time of writing. That helps with sequencing. A HIGH-severity bug with a low EPSS is still a patch item, but the score helps you decide what to do this afternoon versus this week instead of treating every HIGH the same.
The Affected Platforms section pulls the structured CPE entries straight from NVD and shows the exact affected version range for postgresql:postgresql (from 14.0 up to but not including 14.24, with the equivalent ceilings on the other branches). That answers whether your version falls inside the window, and the Track button next to it sends you alerts on future CVEs for the same product and version without checking back manually.
The Remediation section keeps the action short: upgrade to the latest stable release that includes the fix, or apply the vendor patches from PostgreSQL's advisory. The CVE Timeline on the side shows how the record moved from created to published through analysis, so you can gauge how fresh and settled the data is.
The two questions that decide your workload, whether it is in your stack and whether your version matches, land on one screen instead of five.
What to do
If you run PostgreSQL, check every instance against the fixed version for its branch and upgrade: 18.5, 17.11, 16.15, 15.19, or 14.24. Give extra attention to the instances that are easy to forget: managed databases a point release behind, container base images, analytics replicas, and anything that lets an application influence timezone input.
Most teams never see the few CVEs in a day's noise that actually apply to their software. Closing that gap between everything published and the handful that matter to your stack is why VulnTracker exists.
Track CVE-2026-14669 on VulnTracker — tell us you run PostgreSQL and you'd see this in your alerts within hours of disclosure, with the affected version range and EPSS context ready to brief leadership.
Start a 5-day free trial, or get our daily digest free without setting anything up.
Quick reference
| Item | Detail |
|---|---|
| CVE | CVE-2026-14669 |
| Severity | CVSS 8.8 (High) |
| Weakness | CWE-122, heap-based buffer overflow |
| Function | to_char(timestamptz) with a long POSIX timezone abbreviation |
| Impact | Arbitrary code execution as the OS user running PostgreSQL |
| Affected | Versions before 18.5, 17.11, 16.15, 15.19, and 14.24 |
| Fixed in | 18.5, 17.11, 16.15, 15.19, 14.24 (released August 13, 2026) |
| Exploitation | No known in-the-wild exploitation; EPSS low at time of writing |
| Action | Upgrade to the fixed release for your branch, or apply vendor patches |
References: PostgreSQL security advisory · NVD