PHP PDO Emulated Prepares Expose pdo_pgsql to NULL Pointer Dereference Crash

A recent security audit of PHP’s PDO ecosystem uncovered a denial-of-service vector in the pdo_pgsql driver that can crash PHP processes when emulated prepared statements are enabled.

PDO’s parser assumes a valid zend_string and dereferences it, triggering a NULL pointer dereference (SIGSEGV). The issue is tracked as CVE-2025-14180 and rated Moderate (6.3/10).

PDO implements two modes for preparing statements: native prepares, where the client library and server handle parameter binding, and emulated prepares, where PDO performs parameter expansion and escaping on the PHP side before sending a single text query.

When emulation is enabled (PDO::ATTR_EMULATE_PREPARES => true), pdo_pgsql delegates quoting to its quoter callback, which calls libpq’s PQescapeStringConn to escape bytes and produce a quoted zend_string.

If libpq detects an invalid multibyte sequence in the input it sets an error flag and the pdo_pgsql quoter bails out, returning NULL instead of a zend_string. That NULL is then written into the parser’s plc->quoted field.

The PDO SQL parser soon afterwards sums string lengths with the ZSTR_LEN macro, which expands directly to reading the .len field of a zend_string pointer.

Because plc->quoted is NULL, evaluating ZSTR_LEN(plc->quoted) performs a NULL dereference, causing the PHP process to crash.

The practical consequence is a reliable denial of service against PHP workers that process attacker-controlled input while using PDO emulated prepares with pdo_pgsql.

This defect is an example of a common class of bugs where higher-level code assumes successful allocation or return values from lower-level libraries without validating for failure.

PT Security Researchers said that, the fault stems from a gap in error handling between PDO’s SQL parsing logic and PostgreSQL’s libpq escaping routine: under certain malformed inputs, libpq fails and returns NULL during quoting.

Here the root cause is the mismatch between libpq’s error semantics and PDO’s expectations: libpq signals failure via an err flag and the driver returns NULL, but the parser path does not check for NULL before using the result.

PHP PDO ecosystem

The vulnerability was discovered while auditing PDO and its drivers alongside other issues such as a separate SQL injection in pdo_firebird (CVE-2025-14179) and third-party client library flaws in libpq and fbclient documented by the same research team.

PDO (PHP Data Objects) is PHP’s standard database abstraction layer, providing a consistent, object-oriented API for interacting with multiple DBMSs.

Mitigations are straightforward for application owners: disable PDO emulated prepares for PostgreSQL connections by explicitly setting PDO::ATTR_EMULATE_PREPARES to false, which forces native prepares and avoids the vulnerable parser path.

Operators should also ensure their PHP installations are patched with the upstream security release addressing CVE-2025-14180; maintainers have incorporated fixes into routine PHP updates that harden quoting and parser interactions.

The pdo_mysql driver escapes the data itself, interpolates it into the SQL template, and sends a single fully formed text query to the server.

Developers should audit code paths that perform quote-then-prepare workflows, and avoid relying on PDO::quote followed by PDO::prepare with emulation enabled against backends that use external client libraries with complex encoding rules.

For technical background and reproduction details, see the PHP security advisory for CVE-2025-14180 and the PDO SQL parser sources in the PHP repository.

The broader audit and related findings including the pdo_firebird SQL injection via NUL bytes (CVE-2025-14179), and a libpq integer overflow leading to DoS are described in the Positive Technologies write-ups: “Hack the Elephant One Bite at a Time: JPEG-Related Memory-Safety Bugs in PHP”.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.