CVE-2026-6637

What it actually does

This vulnerability affects PostgreSQL installations that include/use the contrib module "refint". A stack buffer overflow in the refint module can allow a low-privileged database user to corrupt process memory and execute arbitrary code with the privileges of the operating system account running the PostgreSQL server process. Separately, when an application declares a user-controlled column as a refint cascade primary key and allows user-controlled updates to that column, SQL injection may allow the attacker to execute arbitrary SQL as the database role performing the primary key update. The impact is full compromise of database confidentiality, integrity, and availability, and potentially operating-system-level compromise within the permissions of the PostgreSQL service account.

Why it matters to the business

A successful attack can turn ordinary database access into control over the database server process, enabling theft or alteration of sensitive records, disruption of database services, deployment of persistence, or further movement from the database host. Because PostgreSQL is commonly used for critical application backends, affected systems may expose business-critical data and applications to compromise even when attackers only have low-privileged database credentials. Although this issue is not currently listed in CISA KEV and public exploit maturity is reported as none, the high CVSS score and low-complexity network attack path make timely remediation important.

How an attack unfolds

An attacker first needs the ability to authenticate to PostgreSQL as an unprivileged database user, or must reach an application path that performs unsafe refint-related primary key updates using attacker-controlled input. For the memory-corruption path, the attacker identifies whether the refint module is installed and whether callable refint trigger functions or related objects are accessible. They then submit crafted SQL or trigger-driving data that causes the refint module to copy attacker-controlled content into a fixed-size stack buffer, corrupting adjacent stack memory. With a reliable exploit, the attacker redirects execution inside the PostgreSQL backend process and runs code as the operating system user that owns the database service. For the alternate SQL-injection path, the attacker supplies a malicious primary key update value to an application that uses a user-controlled column as a refint cascade primary key; the refint cascade logic constructs or executes SQL unsafely, causing attacker-supplied SQL to run as the database role performing the update.

How to fix it

Upgrade PostgreSQL to a fixed release: 18.4 or later, 17.10 or later, 16.14 or later, 15.18 or later, or 14.23 or later, depending on the deployed major version. If immediate upgrade is not possible, remove or disable use of the refint module where it is not strictly required, revoke execute privileges on refint-related functions from untrusted roles, and review trigger definitions that invoke refint functionality. Avoid designs where user-controlled columns are declared as refint cascade primary keys, and ensure application inputs used in primary key updates are strongly validated and parameterized. Restrict direct PostgreSQL access to trusted networks, enforce least-privilege database roles, and run PostgreSQL under a dedicated low-privilege operating system account. Because memory-corruption exploitation may require service restart during patching, plan maintenance windows and validate application compatibility after upgrading.

How to confirm the fix worked

Confirm the PostgreSQL server version is one of the fixed versions or newer by running SELECT version(); or checking the package manager version. Inventory use of refint by checking installed extensions, contrib module objects, and triggers that reference refint functions. Validate that untrusted roles cannot execute refint-related functions and cannot update refint-managed primary key columns unless explicitly required. For packaged deployments, confirm that the installed PostgreSQL package corresponds to 18.4+, 17.10+, 16.14+, 15.18+, or 14.23+. After remediation, retest application workflows that rely on referential-integrity triggers and verify PostgreSQL logs no longer show crashes or errors associated with crafted refint activity.

Typical attack path

1. Obtain low-privileged PostgreSQL credentials or access to an application feature that writes to refint-managed columns.
2. Determine whether the refint module/extension or refint trigger functions are present and reachable.
3. Exercise refint trigger behavior or an application update path using crafted values.
4. For the buffer overflow path, send input designed to overflow the stack buffer in the PostgreSQL backend process.
5. Achieve arbitrary code execution as the operating system user running PostgreSQL, or execute arbitrary SQL through the refint cascade primary key SQL-injection path.
6. Use the resulting access to read, modify, or delete database data, create persistence, dump credentials/secrets available to the database process, or disrupt database availability.

How to detect it

Review PostgreSQL server logs, operating system audit logs, EDR telemetry, and application logs for signs of exploitation. Focus on databases where refint is installed or where triggers call refint functions. Look for PostgreSQL backend crashes, segmentation faults, unexpected server process restarts, abnormal child process execution from the PostgreSQL service account, unusual COPY PROGRAM usage, creation of untrusted procedural languages or C-language functions, suspicious role or permission changes, and anomalous SQL errors around trigger execution or primary key updates. For the SQL-injection variant, inspect application and database logs for primary key update requests containing SQL metacharacters, stacked queries, comments, or attempts to alter roles, create functions, or run file/program operations. If threat hunting at the host level, search for processes spawned by postgres/postmaster that are not part of normal PostgreSQL operation, unexpected files written in PostgreSQL data directories or temporary directories, and outbound network connections initiated by the PostgreSQL service account. No named threat actor activity or KEV exploitation is currently indicated in the provided data, so detections should focus on behavioral evidence rather than actor-specific tooling.

• segmentation fault
• server process was terminated by signal 11
• server process was terminated by signal SIGSEGV
• terminating any other active server processes
• all server processes terminated; reinitializing
• refint
• check_primary_key
• check_foreign_key
• ERROR: syntax error at or near
• COPY PROGRAM
• CREATE EXTENSION plpythonu
• CREATE EXTENSION plperlu
• CREATE FUNCTION
• LANGUAGE C
• ALTER ROLE
• ALTER USER
• GRANT superuser
• pg_read_file
• pg_write_file
• lo_import
• lo_export
• /tmp/
• postgres:
• postmaster

What your security team should do

• Prioritize patching PostgreSQL servers where untrusted users have database login access, where applications expose user-controlled update paths, or where the refint module is installed.
• Upgrade to PostgreSQL 18.4, 17.10, 16.14, 15.18, or 14.23 or later according to the deployed major version.
• Immediately inventory databases for refint usage, including installed contrib objects and triggers referencing refint functions.
• Temporarily disable or restrict refint functionality if patching must be delayed, especially in databases with low-privileged or multi-tenant database users.
• Review application code paths that allow primary key updates on refint cascade primary key columns and ensure input is parameterized and not user-controlled where possible.
• Restrict PostgreSQL network exposure and require strong authentication for all database roles.
• Review PostgreSQL logs for recent backend crashes, suspicious refint-related errors, unexpected SQL execution, role changes, file writes, or creation of unusual database functions.
• Monitor vendor advisories and distribution package repositories for backported fixed builds if using OS-supplied PostgreSQL packages.