PostgreSQL CVE-2026-6637: Brief Summary of the refint Stack Buffer Overflow and SQL Injection

Introduction

A stack buffer overflow and SQL injection in PostgreSQL's refint module give an unprivileged database user a path to arbitrary code execution at the operating system level, earning a CVSS 8.8 score. The flaw sits in example code that ships with every PostgreSQL installation and, despite the vendor's characterization of contrib/spi as sample code, has found its way into production environments where it introduces serious risk across all supported major versions from 14 through 18.

Technical Information

Vulnerable Component and Root Cause

The vulnerability originates in the check_foreign_key() trigger function located in contrib/spi/refint.c. This module implements referential integrity checks through PostgreSQL's Server Programming Interface (SPI). According to the release notes, this function was insufficiently careful about quoting key values and utilized fixed length buffers for constructing queries. Two distinct flaws existed in how this function dynamically constructed SQL statements.

Flaw 1: Fixed Size Stack Buffer (Stack Buffer Overflow, CWE-121)

The old code allocated a fixed 8 KB stack buffer to hold internally generated SQL queries:

char sql[8192];

It then built queries using repeated calls of the form:

snprintf(sql + strlen(sql), sizeof(sql) - strlen(sql), ...);

If the constructed query, driven by user controlled key values and column names, exceeded 8192 bytes, the writes would overflow the stack buffer. This enables arbitrary code execution as the OS level user running the PostgreSQL database service. The attack requires only an unprivileged database user who can supply sufficiently long key values to the trigger function.

Flaw 2: Missing Value Escaping (SQL Injection, CWE-89)

When constructing UPDATE queries for cascade actions, the old code attempted to determine whether a column needed quoting by comparing its type name against a hardcoded list (text, varchar, char, bpchar, date, timestamp). If the type matched, the value was wrapped in bare single quotes with no escaping at all. The vulnerable code path looked like this:

snprintf(sql + strlen(sql), sizeof(sql) - strlen(sql),
         " %s = %s%s%s %s ",
         args2[k], (is_char_type > 0) ? "'" : "",
         nv, (is_char_type > 0) ? "'" : "", (k < nkeys) ? ", " : "");

A value like '; DROP TABLE important; -- would be interpolated directly into the SQL string, giving an attacker who controls the primary key update value the ability to execute arbitrary SQL. This second attack vector is exploitable when an application declares a user controlled column as a refint cascade primary key and facilitates user controlled updates to that column. In that scenario, the attacker executes arbitrary SQL as the database user performing the primary key update.

Attack Flow

1. The attacker identifies a PostgreSQL deployment using the refint module with cascade primary key triggers configured on a table where they can influence key values.
2. For the buffer overflow path: The attacker supplies an extremely long key value (exceeding the 8192 byte buffer) through a normal database operation that fires the check_foreign_key() trigger. The overflow corrupts the stack, and with a crafted payload, the attacker achieves code execution as the OS user running PostgreSQL.
3. For the SQL injection path: The attacker supplies a specially crafted primary key update value containing SQL metacharacters (e.g., single quotes followed by arbitrary SQL). Because the is_char_type logic wraps the value in bare quotes without escaping, the injected SQL is executed with the privileges of the database user performing the update.

Patch Information

The PostgreSQL Global Development Group addressed CVE-2026-6637 in a single commit (1ebda7da9) authored by Nathan Bossart and committed by Noah Misch on May 11, 2026. The fix was published on May 14, 2026, shipping in minor releases 18.4, 17.10, 16.14, 15.18, and 14.23, and was backported through the PostgreSQL 14 branch.

The patch applies two core remediation strategies:

Dynamic Buffer Allocation via StringInfo

All instances of the fixed size char sql[8192] buffer were replaced with PostgreSQL's StringInfoData abstraction, initialized with initStringInfo(&sql). This buffer grows dynamically as needed, completely eliminating the overflow risk. Query fragments are now appended using appendStringInfo() and appendStringInfoString() instead of the fragile snprintf + strlen chain. The dynamically allocated memory is freed after use with pfree(sql.data).

Proper Literal Quoting via quote_literal_cstr()

The entire block of manual type checking code (the is_char_type logic and the associated strcmp calls for text, varchar, etc.) was removed entirely. In its place, new key values are now passed through quote_literal_cstr(nv), which is PostgreSQL's standard C utility for safely escaping and quoting literal values in SQL. This single call handles all data types correctly and escapes special characters, closing the SQL injection vector.

The old vulnerable code in the cascade UPDATE path:

snprintf(sql + strlen(sql), sizeof(sql) - strlen(sql),
         " %s = %s%s%s %s ",
         args2[k], (is_char_type > 0) ? "'" : "",
         nv, (is_char_type > 0) ? "'" : "", (k < nkeys) ? ", " : "");

was replaced with:

appendStringInfo(&sql, " %s = %s ",
                 args2[k], quote_literal_cstr(nv));
if (k < nkeys)
    appendStringInfoString(&sql, ", ");

The same pattern of fixes was applied in check_primary_key() as well, even though that function was only vulnerable to the buffer overflow (it used parameterized queries rather than string interpolation for values). In both functions, the for loop indexing was also cleaned up (changing for (i = 0; i < nkeys; i++) to for (i = 1; i <= nkeys; i++)) to match the 1 based indexing used by the argument arrays, simplifying the offset arithmetic.

Affected Systems and Versions

The vulnerability impacts all PostgreSQL installations using the refint module across the following version ranges:

The specific vulnerable configuration requires the contrib/spi module (refint) to be active. The SQL injection vector additionally requires that the application declares a user controlled column as a refint cascade primary key and facilitates user controlled updates to that column.

References

• PostgreSQL Security Advisory for CVE-2026-6637
• PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 Release Announcement
• PostgreSQL 18.4 Release Notes
• PostgreSQL 17.10 Release Notes
• PostgreSQL 16.14 Release Notes
• PostgreSQL 15.18 Release Notes
• PostgreSQL 14.23 Release Notes
• Commit 1ebda7da9 (patch diff)