PHP PDO Bugs Expose Firebird SQL Injection and PostgreSQL DoS Risks

PHP has fixed two serious database-layer bugs in PDO that could expose some applications to SQL injection or denial-of-service risks. The issues affect how PHP handles quoted values and malformed input inside database drivers.

The first flaw affects pdo_firebird and allows SQL injection through NUL bytes inside quoted strings. The issue is tracked as CVE-2025-14179 in the PHP Firebird advisory.

The second flaw affects PDO quoting behavior and can lead to a null pointer dereference when PostgreSQL quoting returns a null value. It is tracked as CVE-2025-14180 in the PHP PDO advisory.

Why these PHP PDO flaws matter

PDO is the database abstraction layer many PHP applications use to connect to databases through a common interface. The official PHP PDO documentation describes it as an extension that provides a consistent way to access databases from PHP.

That design makes PDO powerful, but it also means driver-level mistakes can affect real applications even when developers believe they are using safe database patterns. A bug in quoting, parsing, or driver preprocessing can change how a query behaves after the application has already built it.

The latest confirmed fixes appear in the PHP 8 changelog, which lists the pdo_firebird SQL injection fix in the May 2026 releases and the PDO quoting null dereference fix in the December 2025 releases.

Issue	CVE	Affected area	Impact	Severity
NUL byte handling in Firebird quoted strings	CVE-2025-14179	pdo_firebird	SQL injection	High
Null pointer dereference in PDO quoting	CVE-2025-14180	PDO quoting with PostgreSQL	Denial of service	Moderate
Missing error checks during PostgreSQL escaping	CVE-2025-1735	pgsql extension	SQL injection or crash risk	Moderate

Firebird bug turns quoted input into SQL injection

The Firebird flaw shows how a safe-looking quoting step can break later in the driver pipeline. The vulnerable code reconstructs a SQL query token by token after values have already been quoted.

According to the Firebird SQL injection advisory, the driver used strncat() while rebuilding parts of the query. That C function stops at a NUL byte, which can cause the rebuilt query to lose the closing quote around a string.

When the quote boundary disappears, attacker-controlled data that should remain inside a string can become executable SQL. The advisory says this applies to several statement types, including SELECT, INSERT, UPDATE, DELETE, MERGE, WITH, and EXECUTE.

• The vulnerable driver is pdo_firebird.
• The issue involves NUL bytes inside quoted strings.
• The bug can break intended string boundaries during query reconstruction.
• Attackers may use the flaw to inject SQL if they control nearby input.
• The issue was credited to Aleksey Solovev and Nikita Sveshnikov of Positive Technologies.

PostgreSQL path can crash PHP through PDO quoting

The PostgreSQL-related PDO issue is different. It does not create a direct data-theft path by itself, but it can crash the PHP process when a quoted value becomes null and PDO tries to read it as though it were valid.

The PDO null pointer advisory says the vulnerable code calls ZSTR_LEN on a quoted value inside PDO’s SQL parser. When PostgreSQL quoting returns null for a special character sequence, PDO can dereference a null pointer and trigger a segmentation fault.

The advisory specifically notes that enabling PDO::ATTR_EMULATE_PREPARES is key to reproducing the crash. That makes the issue especially relevant for applications that enable emulated prepared statements while accepting user-controlled text fields.

Risk area	Firebird issue	PostgreSQL PDO issue
Main weakness	NUL byte handling in query reconstruction	Null pointer dereference during quoting
Main impact	SQL injection	PHP process crash
Attacker input	Quoted string containing a NUL byte	Special invalid byte sequence
Likely result	Unexpected SQL execution	Denial of service
Best fix	Upgrade PHP to a patched build	Upgrade PHP and avoid unnecessary emulated prepares

A related PostgreSQL escaping issue adds context

A separate PHP PostgreSQL advisory from 2025 also matters here because it shows the same class of risk: PHP extensions must properly check errors returned by database client libraries.

In the pgsql escaping advisory, PHP maintainers said missing error checking could cause SQL injection and missing error handling could lead to crashes through null pointer dereferences. The advisory is tied to CVE-2025-1735.

Together, these bugs show that database safety depends on more than application-level prepared statements. It also depends on how language runtimes, extensions, and database client libraries handle unusual bytes, encoding errors, and null returns.

Fixed PHP versions administrators should install

The Firebird SQL injection fix landed in PHP 8.2.31, 8.3.31, 8.4.21, and 8.5.6. Older builds in those branches remain exposed if they include and use the pdo_firebird extension.

The PDO quoting null pointer issue was fixed earlier in PHP 8.1.34, 8.2.30, 8.3.29, 8.4.16, and 8.5.1. Administrators can confirm the release entries in the PHP changelog.

Applications that use packaged PHP from Linux distributions should check vendor advisories as well. Distribution maintainers may backport security patches without changing the upstream PHP version number in the same way.

Vulnerability	Patched PHP versions	Action
CVE-2025-14179	8.2.31, 8.3.31, 8.4.21, 8.5.6	Update if pdo_firebird is installed or used
CVE-2025-14180	8.1.34, 8.2.30, 8.3.29, 8.4.16, 8.5.1	Update PHP and review emulated prepares
CVE-2025-1735	8.1.33, 8.2.29, 8.3.23, 8.4.10	Update if using the pgsql extension

What developers should change in PHP database code

Developers should avoid building SQL by stitching quoted strings into query text where possible. Prepared statements with bound parameters remain the safer default for most database-backed applications.

The official PDO manual gives developers the common interface, but driver-specific behavior still matters. Applications should test database code with the exact drivers and PHP versions they run in production.

Teams should also review cases where PDO::ATTR_EMULATE_PREPARES is enabled. Native prepared statements can reduce exposure to some quoting and parsing edge cases, although compatibility requirements may still force emulation in specific environments.

1. Upgrade PHP to a patched version or a vendor build that includes the fix.
2. Check whether pdo_firebird, pdo_pgsql, or pgsql extensions are installed in production.
3. Avoid manual SQL construction with quoted user input where prepared statements can be used.
4. Disable emulated prepared statements unless the application specifically needs them.
5. Validate and normalize binary or unusual encoded input before it reaches database code.
6. Wrap financial, order, and inventory operations inside database transactions.
7. Monitor PHP worker crashes, segmentation faults, and sudden spikes in 500 errors.

Why this is more than a niche driver problem

Some organizations may not use Firebird, but the broader lesson applies to every database-backed PHP application. A driver can turn unusual input into a security issue even when application developers believe their database code is protected.

The PostgreSQL escaping advisory also shows why extensions must treat library errors as security-sensitive events. If a database client library signals failure and PHP code does not handle it correctly, the result can be injection, a crash, or undefined behavior.

For production teams, the fix is straightforward but urgent: keep PHP current, understand which PDO drivers are enabled, and do not assume low-level database handling is automatically safe because the codebase is mature.

Bottom line

The confirmed PHP PDO issues show how small C-level assumptions can affect high-level web application security. Firebird users face a high-severity SQL injection risk in unpatched builds, while PostgreSQL-related PDO quoting behavior can crash PHP under specific conditions.

Administrators should update affected PHP branches, review enabled database extensions, and audit code paths that rely on quoting rather than bound parameters. Developers should also treat malformed binary and encoded input as dangerous before it enters database workflows.

FAQ