PostgreSQL's August release: 28 CVEs, and your pg_dump needs the patch too

On August 13 the PostgreSQL Global Development Group released 18.6, 17.11, 16.15, 15.19 and 14.24, along with the third beta of PostgreSQL 19. The release closes 28 security vulnerabilities and fixes more than 110 bugs. What stood out to me was not the count but where some of the bugs live: several are in client programs like psql and pg_dump, not in the server most people picture when they say "patch Postgres."

Where the 28 CVEs sit#

The project's security page tags every CVE with a component. For this release that works out to 18 in the core server, 6 in contrib modules and 4 in client programs. Fourteen score CVSS 8.8, the batch's highest, and most of those are memory-safety bugs, several described as executing arbitrary code: heap buffer overflows in regular expressions (CVE-2026-14664), to_char (CVE-2026-14669) and, on the contrib side, pg_stat_statements (CVE-2026-14676, PostgreSQL 18 only). Integer wraparound bugs in tsvector/tsquery and fuzzystrmatch score the same.

Two cross the line between server and tooling:

• CVE-2026-15741 (8.8): deparsing an EXTRACT() expression allows SQL injection, so an object owner can get arbitrary SQL executed as a superuser through a hostile object definition. The advisory says it affects deparse consumers broadly, including pg_dump and psql's \sf.
• CVE-2026-6464 (8.1): if COPY FROM STDIN or \copy FROM STDIN fails before the server signals that it is waiting for rows, psql processes the inline data lines as psql commands. COPY FROM with a filename is not affected, and a full attack usually needs control of both the server and the data rows.

The client side is the part teams forget#

Besides CVE-2026-6464, the client CVEs are:

• CVE-2026-19385: a heap buffer overflow in pg_dump with long function transform lists lets an object creator run code as the OS user running pg_dump.
• CVE-2026-18408: the \restrict and \unrestrict meta-commands were added to fix CVE-2025-8714, and it turns out \unrestrict was enough for an attack by itself. A malicious superuser on the origin server can plant code that runs as the OS account restoring the dump through psql. pg_dumpall is affected too, and so is pg_restore when it produces plain-format output.
• CVE-2026-16241: an ECPG integer underflow that can crash the client.

Think about where pg_dump and psql run: the nightly backup container, the CI image that restores a sanitized dump before integration tests, the bastion used to copy production into staging, developer laptops. None of those move when the server rolls to 18.6, and they often hold credentials for more than one database.

This is not a one-off: per the same security page, the previous minor release fixed client-side bugs in libpq's lo_* functions, pg_basebackup and pg_rewind. Client tooling is attack surface and needs the server's patch cadence.

Three post-update steps#

A minor release is usually stop, swap binaries, start. This one has follow-ups:

• GIN indexes: parallel GIN index builds could leave a table's reltuples at a bogus value, including Infinity or NaN. That can stop autovacuum and autoanalyze from processing the table, and it does not fix itself. Run ANALYZE on any table whose value looks wrong.
• btree_gist: reindex btree_gist indexes on float4/float8 columns that might contain NaN, and on bit/bit varying columns.
• ltree: B-tree indexes over ltree values with more than about 14,653 labels may be corrupt and should be reindexed.

The announcement includes a GIN check query; my version matches the access method by name:

SELECT DISTINCT t.oid::regclass AS table_name, t.reltuples
FROM pg_index i
JOIN pg_class ic ON ic.oid = i.indexrelid
JOIN pg_am am    ON am.oid = ic.relam
JOIN pg_class t  ON t.oid = i.indrelid
WHERE am.amname = 'gin';

Two details for anyone scripting upgrades. There is no 18.5: it was not shipped because of a regression, so 18 goes from 18.4 to 18.6. And on 14, 15 and 16, this release fixes a self-deadlock where a standby replaying WAL from a primary on an older minor version could get stuck, a regression from the previous round of minors. Worth knowing if you update standbys before the primary.

PostgreSQL 14 has three months left#

PostgreSQL 14 stops receiving fixes on November 12, 2026, so 14.24 is one of its last updates. If you are still on 14, the upgrade needs a date now, not in October.

Further ahead, 19 Beta 3 reverts GROUP BY ALL and fixes several issues in the new FOR PORTION OF syntax and logical replication sequence synchronization. It is not for production, but the project asks people to run real workloads against it.

My take#

Postgres is in several of my stacks, including a PostGIS-backed travel app, and the lesson is that "the database" is a set of binaries spread across many machines, not one server. The list I would hand a team on Monday:

• Inventory every place that ships psql, pg_dump, pg_restore or libpq: base images, CI runners, backup jobs, bastions, laptops. Bump them to the matching minor.
• Patch servers and roll replicas deliberately, especially on 14 to 16.
• Run the GIN reltuples check, then reindex btree_gist and ltree indexes where they apply.
• Treat restoring a dump from a server you do not fully control as running untrusted code, because CVE-2026-18408 shows it can be exactly that.
• Put the PostgreSQL 14 upgrade on the calendar.