By ByteBot
PostgreSQL 18.6 dropped on August 13 with 28 security fixes — the most the project has ever shipped in a single release. Two of them are CVSS 8.8 remote code execution bugs reachable by any authenticated database user, not just superusers. A third lets anyone holding REPLICATION privilege load arbitrary code by picking a malicious logical decoding plugin. And if you patched the server but forgot the client tools, three more CVEs in pg_dump and psql still have you exposed. AWS RDS support arrived on August 25. If you’re still on PostgreSQL 14, this is the last patch you’ll ever receive.
Two RCE Bugs Any Authenticated User Can Trigger
The headliners are a pair of CVSS 8.8 vulnerabilities in functions that appear in ordinary production workloads.
CVE-2026-14664 is a heap buffer overflow in PostgreSQL’s regexp match and split functions. Pass invalidly-encoded data to a regexp function — which any SQL user can do — and the server writes past the end of its conversion buffer, handing code execution to the attacker as the OS user running PostgreSQL. If your application uses pattern matching in SQL, this code path runs on every query.
CVE-2026-14662 hits full-text search: crafted oversized input to to_tsvector() or to_tsquery() triggers an integer wraparound in the allocation, writes out of bounds, and produces the same outcome. A related flaw (CVE-2026-6473) was fixed in an earlier release, but the research team found additional code paths with the same problem.
A third heap overflow, CVE-2026-14669, lives in to_char() with a long time zone abbreviation — this one has confirmed active exploitation reports.
The practical implication: these are not obscure functions. They sit in search forms, reporting queries, and data transformation pipelines. If your application accepts user-influenced data that reaches any of these paths, you have an active attack surface.
The Client-Side Vulnerabilities Most Teams Will Miss
Operations teams patch the server binary and move on. This release has three CVEs in the client tools — and they’re easy to miss because they live in the package you install on developer laptops and CI systems, not the server you’re monitoring.
CVE-2026-18408 (CVSS 8.8): A 2025 patch introduced \restrict and \unrestrict psql meta-commands to block a known code injection path in pg_dump. The fix worked. The problem is that \unrestrict itself turned out to be exploitable — a malicious superuser on the server you’re dumping from can inject arbitrary code that runs as the local OS user on the machine running pg_dump. pg_dumpall and pg_restore in plain-format mode are also affected. If you’ve ever pointed pg_dump at a database you don’t fully control, this is relevant.
CVE-2026-19385: A heap buffer overflow in pg_dump triggered by long function transform lists created by any object creator in the database. Same result — code execution as the user running pg_dump.
CVE-2026-6464 (CVSS 8.1): When COPY FROM STDIN fails early, psql processes the remaining data lines as psql commands. That’s command injection into an interactive session.
The fix here requires updating postgresql-client packages separately from the server. On Debian and Ubuntu, that’s a different package. Your CI pipelines, bastion hosts, and Docker images that run pg_dump against production all need updates.
REPLICATION Privilege Can Now Load Arbitrary Libraries
CVE-2026-6471 (CVSS 7.2): Any user holding the REPLICATION privilege can create a logical replication slot with an arbitrary plugin parameter. PostgreSQL does not validate that parameter against superuser status — it just calls dlopen() on whatever shared library path the user provides. Any .so file readable by the server process can be loaded and executed. Deployments using Debezium, pglogical, or any change data capture pipeline should verify which users hold REPLICATION privilege and audit what those users can reach.
-- Check who holds REPLICATION privilege
SELECT usename, userepl FROM pg_user WHERE userepl = true;How to Upgrade (Minor Version Takes Minutes)
Good news: minor version upgrades are binary-compatible. No dump and reload, no pg_upgrade, no migration scripts.
# Update server package (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install postgresql-18
# Also update client tools -- this is the step teams miss
sudo apt-get install postgresql-client-18
# Verify installed version
psql --versionFor high-availability deployments: patch the standby first, confirm replication catches up, fail over, then patch the former primary.
Two post-upgrade checks the release notes specifically flag: if you use GIN indexes, validate reltuples values for their tables; if you use the btree_gist or ltree extensions, reindex affected indexes. The first three security entries in the official release notes also describe configuration adjustments that may apply depending on your setup.
PostgreSQL 14 Ends Support on November 12
The 18.6 release was also the last patch for PostgreSQL 14. November 12, 2026, is the official end-of-life date, and the PostgreSQL project appended EOL warnings to the 14.24 security advisories. Forty-four CVEs were patched in PostgreSQL 14 in 2026 alone. After November 12, any vulnerability discovered in version 14 will go unfixed.
If you’re on PostgreSQL 14, use pg_upgrade to move to PostgreSQL 17 (supported through November 2029). Extended support vendors exist, but they’re a bridge, not a substitute for upgrading.
AWS RDS Users
Amazon added 18.6, 17.11, 16.15, 15.19, and 14.24 to RDS on August 25 — twelve days after the upstream release. You can trigger the upgrade from the AWS console or CLI. RDS minor version upgrades happen during your next maintenance window by default, or you can apply them immediately. The AWS announcement has the full list of affected versions.
The full release announcement and complete CVE list are on postgresql.org.
