Massive PostgreSQL Update: 11 Vulnerabilities Patched as Version 14 Hits End-of-Life Warning

The PostgreSQL Global Development Group has issued a synchronized security update across all actively supported branches, eliminating 11 unique vulnerabilities and resolving more than 60 underlying functional bugs.

Database administrators and DevOps teams are facing an immediate patching cycle following the release of PostgreSQL versions 18.4, 17.10, 16.14, 15.18, and 14.23. The security fixes address a wide range of flaw vectors, including critical local code execution vulnerabilities and logic-subverting SQL injections.

Crucially, maintainers appended an end-of-life (EOL) warning to this advisory: PostgreSQL 14 will officially stop receiving security fixes on November 12, 2026. Organizations still running version 14 environments are urged to finalize their migration plans to a newer release line before the winter deadline.

While the update patches over a dozen separate entry points, two specific security issues represent the highest risk to multi-tenant or application-backed database environments.

Four of the eleven vulnerabilities patched in this cycle earned a severe 8.8 CVSS v3.1 base score, representing significant threats to database integrity and underlying operating systems.

1. Stack Overflows and Code Execution via ‘refint’ (CVE-2026-6637)

A critical stack buffer overflow was uncovered in the legacy refint module. If an unprivileged database user exploits this flaw, they can break out of the database context entirely and execute arbitrary code with the privileges of the operating system user running the database engine.

Furthermore, the vulnerability introduces a secondary risk vector involving SQL injection. If an application uses a user-controlled column as a refint cascade primary key—and permits users to update that column—an attacker can inject malicious SQL payloads. These payloads execute seamlessly under the security context of the database user performing the primary key update.

Impacted Versions: 14 through 18 (Fixed in 18.4, 17.10, 16.14, 15.18, and 14.23).

2. Client Memory Corruption via libpq lo_* Functions (CVE-2026-6477)

The danger isn’t confined strictly to the server side. An inherently risky internal function, PQfn(…, result_is_int=0, …), utilized across several PostgreSQL libpq Large Object functions—specifically lo_export(), lo_read(), lo_lseek64(), and lo_tell64()—presents a severe client-side threat.

Reminiscent of the notorious C standard library function gets(), this implementation blindly copies arbitrary-length, server-determined data into a client buffer without validating size limits. Because core client utilities like psql (via the \lo_export command) and the backup utility pg_dump rely on lo_read(), a malicious or compromised database superuser can exploit this connection to overwrite the stack memory of pg_dump or psql, leading to client-side code execution.

Impacted Versions: 14 through 18 (Fixed in 18.4, 17.10, 16.14, 15.18, and 14.23).

3. Server Allocation Integer Wraparounds (CVE-2026-6473)

An integer wraparound vulnerability exists across multiple server features. By providing carefully crafted application input, an attacker can manipulate calculation metrics to force the server into undersizing its memory allocations. When the application attempts to populate the undersized memory space, it triggers an out-of-bounds write, inducing a segmentation fault and crashing the server instance. Impacted Versions: 14 through 18 (Fixed in 18.4, 17.10, 16.14, 15.18, and 14.23).

4. Backup Utilities File Overwrite (CVE-2026-6475)

A flaw involving improper symlink validation inside pg_basebackup (when operating in plain format) and pg_rewind opens the door for filesystem hijacking. An origin superuser can exploit this behavior to step outside intended directories and overwrite arbitrary local files on the system host, such as the Postgres user’s .bashrc file. However, the PostgreSQL project notes that a post-attack server restart naturally trusts the origin superuser anyway due to native architecture choices like shared_preload_libraries.

Consequently, this exploit holds practical weight only if an administrator takes specific structural steps between running the utilities and restarting the engine, such as migrating files to a separate VM or taking a cold VM snapshot.

Impacted Versions: 14 through 18 (Fixed in 18.4, 17.10, 16.14, 15.18, and 14.23).

Beyond the critical flaws above, several high- and medium-severity vulnerabilities were addressed that target logical replication and privileges.

Privilege Escalations via pg_createsubscriber (CVE-2026-6476) — CVSS 7.2For modern deployments leveraging subscription models, a SQL injection flaw was discovered in the pg_createsubscriber utility. An attacker who already possesses pg_create_subscription rights can manipulate subscription names to inject arbitrary SQL code. The injected commands are executed with full superuser privileges the next time pg_createsubscriber is invoked.

• Impacted Versions: 17 and 18 only (Fixed in 18.4 and 17.10; versions below 17 are unaffected).

Schema and Type Hijacking (CVE-2026-6472) — CVSS 5.4A missing authorization check during CREATE TYPE operations fails to properly validate the multirange schema CREATE privilege. This authorization gap permits a low-privileged object creator to effectively “hijack” queries executed by other database users. If a victim runs a query that relies on the system search_path to locate user-defined or extension-defined types, the system can be manipulated into executing arbitrary SQL functions chosen by the attacker.

• Impacted Versions: 14 through 18 (Fixed in 18.4, 17.10, 16.14, 15.18, and 14.23).

Logical Replication Exploits (CVE-2026-6638) — CVSS 3.7A minor-rated but notable SQL injection flaw exists within logical replication processes, specifically during the execution of ALTER SUBSCRIPTION … REFRESH PUBLICATION. A malicious subscriber table creator can craft table names that force the execution of arbitrary SQL commands, utilizing the publication-side credentials tied to that subscription. The attack triggers seamlessly upon the next scheduled or manual REFRESH PUBLICATION routine.

• Impacted Versions: 16 through 18 (Fixed in 18.4, 17.10, and 16.14; versions below 16 are unaffected).

The remainder of the patches cover cryptographic timing attacks, unauthenticated network disruptions, and precision memory leaks.

• Network Denial of Service (CVE-2026-6479 / CVSS 7.5): An uncontrolled recursion flaw within the SSL and GSS authentication negotiation phases allows an attacker with access to a PostgreSQL AF_UNIX socket to trigger an infinite loop, causing a sustained denial of service. If both SSL and GSS features are disabled globally, the vulnerability remains reachable via a standard TCP socket.
• Password Timing Channel Leak (CVE-2026-6478 / CVSS 6.5): A covert timing channel in the database’s legacy MD5 password hashing verification engine allows remote attackers to carefully measure response times to systematically recover valid user credentials. While modern installations default to the immune scram-sha-256 protocol, databases that have undergone sequential upgrades originating from PostgreSQL 13 or earlier may still house vulnerable MD5 hashes.
• Time Function Memory Disclosure (CVE-2026-6474 / CVSS 4.3): The timeofday() function was found to contain an externally-controlled format string vulnerability. Attackers passing maliciously crafted timezone strings can force the server into disclosing adjacent fragments of raw server memory.
• Query Planner Array Over-Read (CVE-2026-6575 / CVSS 4.3): Exclusive to the version 18 branch, the pg_restore_attribute_stats() function fails to validate array lengths properly. This buffer over-read allows a malicious table maintainer to force the query planner to read past the end of the statistics array, leaking localized memory structures.

Administrators are urged to schedule downtime to apply these minor updates immediately. As is standard with minor PostgreSQL releases, updating does not require data dumps or structural migrations—simply install the updated binaries and restart the database service.

If your ecosystem relies heavily on database clusters stretching back to PostgreSQL 14, now is the time to finalize upgrade pipelines ahead of the November deprecation deadline.