PostgreSQL August 2026 Security Update: A Safe Minor-Upgrade Runbook

The PostgreSQL Global Development Group released PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 on August 13, 2026. This is not a routine update to postpone until the next maintenance window: it fixes 28 security vulnerabilities and more than 110 bugs across every supported major version.

Several fixed vulnerabilities have a CVSS 3.1 score of 8.8 and can lead to arbitrary code execution. The release also changes logical-decoding plugin policy, corrects a pgcrypto failure mode that could produce weakly protected data, fixes dangerous client and dump/restore behavior, and calls for targeted checks on some indexes after the binaries are updated.

TL;DR
Stay on the current major version, but update to 18.6, 17.11, 16.15, 15.19, or 14.24.
PostgreSQL 18.5 was not shipped because of a regression; the valid PostgreSQL 18 target is 18.6.
PostgreSQL 19 Beta 3 is a test release, not a production security-update target.
A same-major minor update does not require pg_upgrade or dump/restore, but it does require downtime or a controlled failover to replace server binaries.
Inventory logical-decoding plugins before restarting because output_plugin_libraries now defaults to pgoutput,test_decoding.
After the update, inspect GIN table statistics and reindex affected btree_gist or unusually deep ltree indexes.
Update PostgreSQL client tools as well as servers, then prove backup, restore, replication, and application behavior in staging.

Choose the correct target version

Keep the major version constant for this security update:

Current major	Minimum target from the August 13 release	Support note
PostgreSQL 18	18.6	Do not target 18.5; it was not shipped
PostgreSQL 17	17.11	Supported
PostgreSQL 16	16.15	Supported
PostgreSQL 15	15.19	Supported
PostgreSQL 14	14.24	Supported only until November 12, 2026

PostgreSQL 14 teams need two plans: apply 14.24 now, and schedule a major-version migration before end of support. Do not combine those two changes automatically. The urgent security patch is a same-major update with a much smaller compatibility surface; a major upgrade has separate extension, storage, and application-compatibility work.

PostgreSQL 19 Beta 3 was announced on the same day, but the project explicitly advises against using it in production. It belongs in an isolated compatibility environment, not in this rollout.

Why this update deserves priority

The release closes vulnerabilities in both server and client surfaces. Examples include:

type confusion involving internal arguments and cursor portals that can lead to arbitrary server-side code execution;
memory-safety defects in text search, regular expressions, to_char(), PL/Perl, fuzzystrmatch, and statistics restore paths;
a logical-decoding flaw that allowed a replication user to load an arbitrary server library;
a psql scripted COPY FROM STDIN failure mode that could interpret following data as commands;
dump and restore issues that could cause a client to execute code controlled by a privileged source server;
a pgcrypto error path where unsupported legacy ciphers could leave data only trivially protected.

Risk depends on enabled extensions, exposed roles, client workflows, and application inputs, but that is not a reason to patch only clusters that appear vulnerable. The supported update releases are cumulative, and the project released them for every maintained major line.

Treat the server package, command-line clients, backup workers, administrative jump hosts, and CI images as one patch set. Updating the database server while leaving an old psql, pg_dump, or pg_restore binary in automation preserves avoidable client-side exposure.

Inventory before changing anything

Record the exact server version and relevant features from each primary and standby:

SELECT version();
SHOW server_version;

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

SELECT slot_name, slot_type, plugin, active
FROM pg_replication_slots
ORDER BY slot_name;

Also capture replication and recovery state:

SELECT pg_is_in_recovery();

SELECT application_name, state, sync_state, replay_lsn
FROM pg_stat_replication
ORDER BY application_name;

Run the queries with a role authorized to inspect these views, and save the output in the change record rather than in application logs.

Outside the server, inventory every client binary used for backups and administration:

psql --version
pg_dump --version
pg_restore --version

Confirm which package repository, container digest, or managed-database maintenance channel will deliver the patched build. A container tag such as postgres:17 can move over time, so resolve and record the digest actually tested and deployed.

Prepare logical decoding before the restart

The security fix for CVE-2026-6471 introduces output_plugin_libraries, a server parameter that limits logical-decoding output plugins. Its default permits the built-in pgoutput and test_decoding plugins.

If all slots use pgoutput, the default is normally sufficient:

output_plugin_libraries = 'pgoutput, test_decoding'

If a trusted product uses another plugin, add only that reviewed library before restarting the patched server:

output_plugin_libraries = 'pgoutput, test_decoding, my_trusted_decoder'

Do not use a broad wildcard to preserve old behavior. First identify the plugin names from pg_replication_slots, confirm that each library comes from the expected package, and test the consumer with the restricted list.

For a future major upgrade from PostgreSQL 17 or later, pg_upgrade --check also verifies that the new cluster permits plugins used by old logical-replication slots. That check is not part of this same-major update, but documenting the whitelist now prevents the setting from becoming a surprise during the next major migration.

Audit pgcrypto rather than merely restarting

The pgcrypto fix addresses unsupported legacy cipher selections. In affected OpenSSL configurations—FIPS mode is one example—older algorithms such as Blowfish, Twofish, CAST5, or 3DES could be rejected by OpenSSL without the failure being handled safely.

Search application code and stored procedures for explicit legacy cipher options. New encryption should use a supported modern algorithm and must fail closed when the requested cipher is unavailable.

The patched release adds ignore-cipher-failure=1 to help recover previously affected values. Treat it as a narrowly controlled recovery option, not as an application default. The safe process is:

restore a recent backup into an isolated environment;
identify rows produced with the affected configuration;
verify whether the recovery option works under a matching OpenSSL setup;
decrypt and immediately re-encrypt confirmed data with a modern supported algorithm;
rotate any secrets whose confidentiality may have depended on the affected ciphertext;
remove the recovery option and retest normal failure behavior.

Do not experiment on the only production copy. Recovery depends on the cipher availability of the environment that originally produced the values.

Apply the minor update

The PostgreSQL project states that a same-major update requires neither dump/restore nor pg_upgrade. The high-level sequence is:

verify a recent physical backup and a separate logical restore test;
stop writes or perform a controlled failover according to the deployment architecture;
stop the database process on the node being updated;
replace server and client binaries with the patched minor version;
start the server and inspect startup logs;
update standbys and restore the intended replication topology;
run the targeted checks below before declaring the rollout complete.

Package and managed-service commands differ. Follow the vendor's instructions for the operating system, image, operator, or service, but verify that the resulting server reports the exact target version:

SELECT current_setting('server_version') AS server_version;

Do not confuse a client-only upgrade with a server upgrade. psql --version reports the local client, while SHOW server_version reports the connected server.

Run the required post-update checks

Check tables with GIN indexes

A previous parallel GIN build bug could leave pg_class.reltuples as Infinity, NaN, or another unreasonable value. That can prevent autovacuum and autoanalyze from processing the table. After updating, list tables that have a GIN index:

SELECT DISTINCT t.oid::regclass AS table_name, t.reltuples
FROM pg_class AS t
JOIN pg_index AS i ON t.oid = i.indrelid
JOIN pg_class AS ic ON i.indexrelid = ic.oid
WHERE t.relhasindex
  AND ic.relam = 2742;

Review suspicious values against actual table size. Repair an affected table's statistics with ANALYZE during an appropriate maintenance period:

ANALYZE schema_name.table_name;

Reindex affected extension indexes

The release corrects btree_gist behavior for floating-point NaN values and bit or bit varying columns. Reindex indexes matching those conditions after identifying them precisely:

REINDEX INDEX CONCURRENTLY schema_name.index_name;

Use the non-concurrent form only when its stronger lock is acceptable. The announcement shows the general REINDEX INDEX operation; operational mode and disk headroom must be chosen for the installation.

The ltree fix concerns B-tree indexes over unusually deep values—more than roughly 14,653 labels. Most applications will never approach that shape. If one does, identify and reindex the affected indexes rather than rebuilding every index indiscriminately.

Verify replication and clients

Confirm that physical standbys resume streaming and are not stuck replaying WAL:

SELECT application_name, state, sync_state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication
ORDER BY application_name;

Then verify logical replication or change-data-capture consumers. Create a small reversible change in a staging database, observe it at the consumer, and remove the test row. This exercises the configured output plugin instead of merely proving that the slot exists.

Regenerate a test backup with the patched pg_dump and restore it with the patched pg_restore into an empty disposable database. A successful old backup is not evidence that the updated client path works.

Test application compatibility

A database patch is complete only when the application behavior has been checked. At minimum, run:

connection-pool startup and reconnect tests;
representative reads and writes under the application's normal role;
migration-tool validation without applying unrelated migrations;
transaction, retry, and timeout tests;
search features backed by GIN, tsvector, pg_trgm, or regular expressions;
CDC or logical-replication delivery checks;
backup and clean-restore drills;
monitoring checks for autovacuum, replication lag, database errors, and latency.

For application-side rollout strategy, see Zero-Downtime Data Migration and Schema Evolution. Its expand-and-contract approach is useful for separating schema changes from this binary update.

Avoid bundling application schema changes with this patch. Keeping the database binary update separate makes rollback criteria and root-cause analysis far clearer.

Rollout and rollback decision

Promote the update only after the staging environment uses the same PostgreSQL major version, extensions, logical-decoding plugins, OpenSSL policy, client tools, and representative data shapes as production.

A practical rollout order is:

patch backup and administrative clients;
patch a representative staging cluster and complete restore tests;
patch a low-risk production replica or canary cluster;
observe server errors, latency, replication, vacuum activity, and CDC consumers;
continue through the remaining nodes using controlled failovers;
run GIN and extension-specific cleanup checks;
keep the change open until backup and restore verification completes.

Define rollback before the change. Reverting packages may be possible in some deployments, but a tested failover or restore procedure is the dependable safety mechanism. Never roll back by reusing an unverified data directory with older binaries.

The decision is straightforward: supported PostgreSQL 14 through 18 clusters should receive the August 13 security update promptly. Apply the patched minor release within the current major line, include every client that handles trusted or untrusted SQL artifacts, and treat the new logical-decoding policy and targeted data/index checks as part of the upgrade—not as optional follow-up work.