CVE-2026-6477

What it actually does

This vulnerability is a stack-based buffer overflow in PostgreSQL libpq client-side large object handling. A PostgreSQL server controlled by, or influenced by, a database superuser can return an arbitrarily large response to libpq functions that call PQfn(..., result_is_int=0, ...), including lo_export(), lo_read(), lo_lseek64(), and lo_tell64(). Affected client programs such as psql and pg_dump may copy that server-controlled response into a stack buffer without a reliable size bound. Successful exploitation can corrupt client process memory and may lead to client-side code execution, process crash, or disclosure/modification of data accessible to the client process. The issue affects PostgreSQL versions before 18.4, 17.10, 16.14, 15.18, and 14.23.

Why it matters to the business

The main risk is to administrators, automation jobs, backup systems, and operators that connect trusted client tools to an untrusted, compromised, or malicious PostgreSQL server. If exploited, an attacker with effective superuser control of a PostgreSQL server could crash or potentially take over client-side processes such as pg_dump or psql, which may run with elevated local privileges or have access to sensitive credentials and backup destinations. Operationally, this can disrupt database backups, migrations, incident response collection, and administrative workflows. Because pg_dump commonly runs in scheduled backup pipelines, a compromised database server could become a pivot point into backup infrastructure or administrative workstations. The CVSS score is high, but EPSS is currently low and there is no known KEV listing or reported ransomware use in the provided data; remediation should still be prioritized for systems that connect PostgreSQL clients to less-trusted servers or run automated dumps.

How an attack unfolds

An attacker first needs control over a PostgreSQL server in a position to interact with a vulnerable libpq-based client, typically by obtaining PostgreSQL superuser privileges on that server or operating a malicious server that a victim client connects to. The attacker then prepares server-side behavior that returns an oversized response through the vulnerable fast-path function mechanism used by libpq large object operations. When a victim runs an affected client operation, such as using psql with the \lo_export command or running pg_dump against the attacker-controlled server, the client calls vulnerable libpq functions such as lo_read(). The server returns data larger than the client stack buffer can safely hold. The client process overwrites stack memory, causing a crash or, with sufficient exploit reliability, arbitrary code execution in the context of the client process. Any credentials, files, network access, or privileges available to that client process may then be exposed or abused.

How to fix it

Upgrade PostgreSQL client packages and libpq to a fixed release. Fixed PostgreSQL branches are 18.4 or later, 17.10 or later, 16.14 or later, 15.18 or later, and 14.23 or later. Ensure the upgrade covers client-side components, not only database server binaries; vulnerable tools include libpq consumers such as psql and pg_dump. Rebuild or redeploy applications and containers that statically link or bundle libpq. Update backup, migration, ETL, administration, and CI/CD images that include PostgreSQL client utilities. As interim mitigation, avoid connecting vulnerable clients to untrusted or recently compromised PostgreSQL servers, restrict who can obtain PostgreSQL superuser privileges, avoid running pg_dump or psql \lo_export against untrusted servers, and run administrative clients under least-privilege operating system accounts with limited file-system and network access.

How to confirm the fix worked

Confirm the installed PostgreSQL client and libpq versions are at or above the fixed branch version: 18.4, 17.10, 16.14, 15.18, or 14.23. Validate both server and client packages using package manager inventory, container image manifests, and direct tool checks such as psql --version and pg_dump --version. On Linux, also inspect linked libpq versions for applications that use PostgreSQL client libraries. Confirm backup jobs, automation runners, jump hosts, administrator workstations, and container images no longer contain vulnerable PostgreSQL client packages. Where feasible, run a controlled regression test of pg_dump and psql large object export workflows against a trusted patched environment and confirm normal operation without crashes. Exposure remains if any vulnerable client can connect to an untrusted or attacker-controlled PostgreSQL server.

Typical attack path

1. Attacker gains PostgreSQL superuser privileges on a database server or operates a malicious PostgreSQL-compatible server.
2. Attacker prepares a malicious large object or crafted fast-path function response that returns an oversized server-controlled value.
3. A victim administrator, backup job, migration process, or automation connects using a vulnerable PostgreSQL client library or tool.
4. The victim runs an affected operation, commonly pg_dump or psql \lo_export, which invokes vulnerable libpq large object functions such as lo_read().
5. The malicious server sends an arbitrarily large response to the client.
6. The vulnerable client copies the response into an inadequately bounded stack buffer.
7. The client process crashes or the attacker achieves code execution in the context of the user or service account running the client.
8. The attacker uses the compromised client context to access local files, credentials, backup storage, administrative networks, or other systems reachable from that host.

How to detect it

Look for evidence on systems that run PostgreSQL client tools rather than only on database servers. Relevant sources include Linux system logs, kernel logs, crash reporting systems, EDR telemetry, core dump repositories, shell history, backup job logs, scheduler logs, CI/CD runner logs, container logs, PostgreSQL server audit logs, and command execution telemetry. Focus on abnormal crashes or memory corruption in psql, pg_dump, or applications linked to libpq, especially immediately after connecting to a database server or performing large object export/read operations. Search for segfaults, stack smashing detections, aborts, core dumps, and unusual pg_dump failures. Correlate those events with recent PostgreSQL superuser activity, suspicious role changes, unexpected use of large object functions, or administrative clients connecting to servers that were untrusted, newly restored, externally supplied, or suspected compromised. If a client crash occurred while dumping or exporting large objects from a server controlled by a suspicious superuser, preserve the core dump, client binary, linked libpq version, command line, server logs, and network metadata for forensic review. Because exploitation may result only in client-side memory corruption, absence of PostgreSQL server log entries does not rule out exploitation.

• segfault.*psql
• segfault.*pg_dump
• psql.*segfault
• pg_dump.*segfault
• stack smashing detected.*psql
• stack smashing detected.*pg_dump
• core dumped.*psql
• core dumped.*pg_dump
• systemd-coredump.*psql
• systemd-coredump.*pg_dump
• Process psql .* dumped core
• Process pg_dump .* dumped core
• pg_dump: error:.*server closed the connection unexpectedly
• pg_dump: error:.*connection to server was lost
• \lo_export
• lo_export
• lo_read
• lo_lseek64
• lo_tell64

What your security team should do

• Prioritize upgrading PostgreSQL client packages and libpq on administrator workstations, backup servers, automation runners, CI/CD images, migration hosts, and application containers that connect to PostgreSQL.
• Patch to PostgreSQL 18.4, 17.10, 16.14, 15.18, or 14.23 or later, depending on the deployed branch.
• Inventory all copies of psql, pg_dump, libpq, and bundled PostgreSQL client utilities, including statically linked binaries and container images.
• Treat backup and database administration infrastructure as high priority because pg_dump is a known affected execution path.
• Restrict PostgreSQL superuser privileges and investigate any unexpected grants, role changes, or signs of database server compromise.
• Avoid using vulnerable clients against untrusted, third-party, test, recovered, or suspected-compromised PostgreSQL servers until clients are patched.
• Run database client tools with least-privilege operating system accounts and limit their access to sensitive local files and network destinations.
• Review recent psql and pg_dump crashes, core dumps, and abnormal terminations for possible exploitation attempts.
• If exploitation is suspected, rotate credentials accessible to affected client processes and review backup storage, administrative hosts, and connected systems for follow-on activity.