The vulnerability arises from PostgreSQL’s libpq function PQfn when used with result_is_int=0, which writes server‑controlled data of arbitrary length into a client buffer without bounds checking. The lo_* wrapper functions such as lo_export, lo_read, lo_lseek64, and lo_tell64 invoke this unsafe routine, allowing a PostgreSQL superuser to deliver a payload that overwrites the caller’s stack memory. The overflowing data can corrupt return addresses or other control‑flow data on the client side, which can lead to denial of service or potentially arbitrary code execution if the overwritten memory is executed. This flaw is analogous to the classic gets() vulnerability in C programs.

Affected deployments are PostgreSQL database servers using the libpq client library and the provided command‑line utilities psql and pg_dump. Versions of PostgreSQL prior to 18.4, 17.10, 16.14, 15.18, and 14.23 are vulnerable. The flaw affects all OS platforms where these binaries run, as it resides in the client library shared across all hosts communicating with the server.

The CVSS score of 8.8 indicates high severity. Exploitation requires a server superuser and a client that invokes the vulnerable lo_* wrappers. While EPSS data are not available, the absence of a listing in CISA’s KEV catalog suggests that no publicly disclosed exploits have yet been seen, but the flaw is exploitable on any downstream client that has privileged access to the server. Because the payload originates from the server, an attacker who gains superuser status can trigger the corrupting response directly. The lack of mitigation built into the client library makes the vulnerability highly exploitable in environments where servers and clients are co‑located or where trusted administrators are also potential attackers.