PostgreSQL 18.6

The PostgreSQL Global Development Group has released PostgreSQL 18.6, the latest minor version of the 18 series, on August 13, 2026. The update arrives alongside maintenance releases for every supported branch — 17.11, 16.15, 15.19, and 14.24 — and it is first and foremost a security release, closing eight distinct vulnerabilities ranging from arbitrary code execution to memory disclosure.

Notably, 18.5 was never released: a regression discovered after the release candidate was wrapped forced the team to skip straight to 18.6. "This release contains a variety of fixes from 18.4," the official release notes state, with the skipped version accounting for the larger-than-usual fix list.

What Changed

The headline change is a new server parameter, output_plugin_libraries, which restricts logical decoding output plugins to an explicit whitelist. Previously, any replication user could load arbitrary libraries for logical decoding — a lever for exploits. By default only the bundled pgoutput and test_decoding plugins are permitted, and administrators relying on third-party decoders must add them explicitly. The fix closes CVE-2026-6471.

• CVE-2026-14669 — buffer overrun in to_char() with long time zone abbreviations; can crash the server and has been exploited for arbitrary code execution
• CVE-2026-16239 — diverging portal row types in EXECUTE/FETCH could lead to memory disclosure and code execution
• CVE-2026-14664 — buffer overrun in regexp match/split functions on invalidly-encoded data
• CVE-2026-14663 — pgcrypto silently "encrypting" with unsupported ciphers; now fails loudly with a new ignore-cipher-failure escape hatch
• CVE-2026-6464 — psql could misinterpret in-line data after a failed scripted COPY ... FROM STDIN, a SQL-injection hazard
• CVE-2026-18024 — ascii() hardened against invalidly-encoded input
• CVE-2026-16238 — pg_restore_attribute_stats() mishandled multirange types

Why It Matters

Three of these fixes require post-update action, not just a package swap. Sites using GIN indexes should check for possibly-corrupt reltuples values, and installations relying on btree_gist or ltree may need to reindex. Anyone using custom logical decoding output plugins must add them to output_plugin_libraries before restarting — and pg_upgrade --check will now fail if the new cluster does not permit the plugins of existing logical replication slots.

The good news: a dump/restore is not required for users on 18.X. The migration path is a straightforward binary upgrade for most installations.

What's Next

With 19 Beta 3 now in circulation, the community's attention turns toward the next major release. For production users, though, the message is simple: this is a mandatory security update. The full changelog, including all 60+ fixes across every supported branch, is available in the PostgreSQL release notes.