PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 Released

May 14 2026 – PostgreSQL Global Development Group

Why this release matters

The PostgreSQL project has issued a synchronized minor‑release for every actively supported major version. By bundling the same set of security patches and bug‑fixes into 14.23, 15.18, 16.14, 17.10, and 18.4, the community ensures that operators who cannot immediately upgrade to the newest major version still receive the same level of protection. The release fixes 11 documented security vulnerabilities (CVE‑2026‑6472 … CVE‑2026‑6638) and over 60 bugs that have accumulated over the last several months.

The most consequential changes fall into three categories:

1. Privilege‑escalation and code‑execution vectors – several CVEs allow a user with limited rights to execute arbitrary SQL or even native code on the server.
2. Memory‑safety defects – integer wrap‑around and unsafe libpq functions could lead to out‑of‑bounds writes or client‑side stack corruption.
3. Replication and backup integrity – bugs in pg_basebackup, pg_rewind, and logical replication slots could let a superuser overwrite unrelated files or cause denial‑of‑service conditions.

Together, these patches raise the baseline security posture of every PostgreSQL deployment that applies them.

---

Core security issues and their impact

CVE	Brief description	CVSS v3.1	Affected versions	Primary mitigation
2026‑6472	CREATE TYPE does not verify multirange schema privileges, enabling hijacking of search_path lookups.	5.4	14‑18 (pre‑18.4/17.10/16.14/15.18/14.23)	Upgrade to the patched minor releases.
2026‑6473	Integer wrap‑around leads to undersized allocations and out‑of‑bounds writes, causing crashes.	8.8	14‑18 (pre‑patched)	Upgrade; avoid feeding untrusted integer values to vulnerable APIs.
2026‑6474	Format‑string exposure in timeofday() can leak server memory via crafted timezone strings.	4.3	14‑18 (pre‑patched)	Upgrade; restrict control over timezone inputs.
2026‑6475	Symlink traversal in pg_basebackup and pg_rewind lets a superuser overwrite arbitrary files (e.g., .bashrc).	8.8	14‑18 (pre‑patched)	Upgrade; consider using dedicated backup accounts with limited filesystem rights.
2026‑6476	pg_createsubscriber suffers SQL injection when the subscription name is attacker‑controlled.	7.2	17‑18 (pre‑18.4/17.10)	Upgrade; limit pg_create_subscription rights.
2026‑6477	Dangerous PQfn(..., result_is_int=0, …) usage in libpq lo_* functions permits a server superuser to corrupt client stack memory.	8.8	14‑18 (pre‑patched)	Upgrade; avoid running client tools (psql, pg_dump) as privileged OS users when connecting to untrusted servers.
2026‑6478	Timing channel in MD5 password comparison can reveal password hashes.	6.5	14‑18 (pre‑patched)	Upgrade; migrate any remaining MD5‑hashed passwords to SCRAM‑SHA‑256.
2026‑6479	Uncontrolled recursion in SSL/GSS negotiation can cause denial‑of‑service.	7.5	14‑18 (pre‑patched)	Upgrade; disable unused authentication methods if not needed.
2026‑6575	pg_restore_attribute_stats accepts mismatched array lengths, leading to buffer over‑read.	4.3	18 (pre‑18.4)	Upgrade; avoid restoring malformed statistics files.
2026‑6637	refint module permits stack overflow and SQL injection via crafted primary‑key updates.	8.8	14‑18 (pre‑patched)	Upgrade; audit extensions that use refint.
2026‑6638	REFRESH PUBLICATION can be abused for SQL injection through table names.	3.7	16‑18 (pre‑patched)	Upgrade; restrict publication creation to trusted roles.

What the patches actually do

• Privilege checks – The CREATE TYPE fix adds a verification step that ensures the creator has appropriate rights on the target schema, closing the attack surface where a malicious type could be injected into a victim’s search_path.
• Integer safety – Allocation routines now perform explicit overflow detection before casting to size_t. When an overflow is detected, the server aborts the operation with a clear error rather than allocating an undersized buffer.
• Format‑string sanitisation – The timeofday() implementation now treats timezone strings as opaque data, preventing %‑style format specifiers from reaching printf‑style functions.
• Symlink handling – pg_basebackup and pg_rewind now resolve symlinks against a whitelist of safe directories and refuse to follow symlinks that point outside the designated backup area.
• Libpq hardening – The affected lo_* functions now allocate a bounded buffer based on the server‑reported length and reject oversized responses, eliminating the classic “gets()” style overflow.
• Timing‑attack mitigation – Password comparison now uses a constant‑time algorithm for MD5 hashes, matching the approach already used for SCRAM.
• Recursion guard – SSL and GSS negotiation now enforce a maximum recursion depth, returning an explicit error once the limit is reached.

These changes are largely orthogonal to existing functionality; they do not introduce breaking API changes, but they do require a restart of the server after the binary update.

---

Bug‑fix highlights beyond security

While the security patches dominate the announcement, the release also delivers a substantial set of functional improvements:

• Nondeterministic collations – Queries that previously returned incorrect results when a unique index used a nondeterministic collation are now evaluated correctly.
• Foreign‑key trigger deferrability – A regression that caused DEFERRABLE INITIALLY DEFERRED constraints to lose their deferrable property after being toggled to NOT ENFORCED has been repaired. Existing databases can recover by toggling the constraint state as described in the release notes.
• Partition pruning – The planner’s ability to prune partitions has been extended, yielding measurable performance gains for complex partitioned tables.
• Virtual generated columns – INSERT … ON CONFLICT now works when the EXCLUDED clause references a virtual generated column, fixing a long‑standing edge case.
• MERGE serialization failures – In repeatable‑read or serializable isolation levels, MERGE now correctly reports a serialization failure when a concurrently‑updated tuple is encountered.
• CREATE TABLE … LIKE … INCLUDING STATISTICS – The command now respects dropped columns in the source table, preserving expected statistics for the new table.
• WITHOUT OVERLAPS – The operator now accepts domain types, broadening its applicability in exclusion constraints.
• Multirange type safety – The system now rejects attempts to embed a composite type within its own multirange definition, preventing recursive type definitions.
• Parallel array_agg – Parallel aggregation of anyarray no longer yields sporadic incorrect results.
• Incremental backup bloat – Restoration of incremental backups avoids unnecessary table‑space bloat, improving storage efficiency.
• Logical replication slot synchronization – Stuck workers that previously blocked standby promotion have been fixed, enhancing high‑availability reliability.
• pg_aios view – The pid column now reports NULL for entries without an owning process, making the view’s semantics clearer.
• pg_stat_replication lag reporting – Null lag values are now correctly displayed only when replication is truly inactive.
• Startup/shutdown robustness – The postmaster now ensures that child processes are cleanly terminated if the startup sequence fails, and a race condition that could cause a crash‑loop on older‑minor‑version WAL replay has been eliminated.
• Timezone data – The bundle upgrades to tzdata 2026b, reflecting the permanent UTC‑07 offset for British Columbia beginning November 2026 and correcting Moldova’s DST history.

These improvements, while not security‑critical, contribute to the overall stability and performance of PostgreSQL deployments.

---

End‑of‑life notice for PostgreSQL 14

PostgreSQL 14 will stop receiving fixes on 12 November 2026. Operators still running 14.x should plan a migration to a newer major version before that date. The versioning policy (see the official Versioning Policy) recommends a minimum of five years of support; 14 is therefore reaching the end of its guaranteed maintenance window.

How to upgrade

All supported minor releases are cumulative. Updating does not require a dump/restore cycle; a simple binary replacement followed by a server restart is sufficient. The steps are:

1. Stop the PostgreSQL service (e.g., systemctl stop postgresql).
2. Install the new packages from your OS vendor or the official PostgreSQL apt/yum repositories.
3. Start the service (systemctl start postgresql).
4. Verify the version with SELECT version(); and confirm that the server reports the new minor version.
5. If you have skipped earlier minor releases, consult the release notes for each skipped version; some may require additional post‑update actions (e.g., reindexing system catalogs).

For containerised environments, simply pull the updated image tag (e.g., postgres:18.4) and redeploy.

---

Implications for the ecosystem

The coordinated release underscores a mature governance model: the PostgreSQL community treats security as a first‑class citizen across all supported branches, not just the newest major version. This approach mitigates the risk of “legacy‑only” deployments becoming soft targets for attackers.

From an operational perspective, the breadth of the fixes means that any organization that postpones upgrades for convenience now faces a concrete incentive to apply the patches promptly. The CVEs with CVSS scores of 8.8 (e.g., integer wrap‑around, libpq stack overwrite, refint overflow) are in the high‑severity range and could be chained with existing privileges to achieve full system compromise.

The release also highlights the growing complexity of PostgreSQL’s feature set—logical replication, backup tooling, and extensibility via extensions like refint all introduce new attack surfaces. The community’s rapid response to these reports demonstrates an effective vulnerability‑disclosure pipeline, involving external researchers, corporate labs, and internal contributors.

---

Looking ahead

While PostgreSQL 14’s EOL is looming, the project is already laying groundwork for PostgreSQL 19, which will introduce deeper integration with cloud‑native storage engines and expanded support for vectorized execution. The hardening work in this release will serve as a baseline for those future enhancements, ensuring that performance gains do not come at the expense of security.

For now, the prudent course for administrators is to apply the minor‑release updates without delay, audit any remaining MD5 password hashes, and begin planning migration paths away from PostgreSQL 14 before the November deadline.

---

Further reading

• Release notes for 18.4
• Security advisory and CVE list
• Versioning policy
• How to upgrade PostgreSQL