On 30 July 2026 the PHP project released 8.5.9 and 8.4.24 with four security fixes. The one to look at first is CVE-2026-17543, a SQL injection in the PGSQL extension through an E'...' backslash breakout. The others are an out of bounds write in bccomp() (CVE-2026-17544), a crash in Phar from recursive symlinks (CVE-2026-7260) and a libgd upgrade (CVE-2026-9672).
What's affected
Fixed in PHP 8.5.9 and 8.4.24. The changelog lists the Phar fix for both lines and the libgd upgrade as well. Earlier, PHP 8.5.8 on 2 July 2026 fixed a memory corruption in openssl_encrypt with AES-WRAP-PAD (CVE-2026-14355). The changelog does not state the exact affected ranges, so treat anything older than these releases on those branches as in scope.
How to check if you're exposed
php -v
# does the code touch these paths?
grep -rnE "pg_escape_literal|pg_escape_string|pg_query\(|pg_send_query\(" src
grep -rnE "bccomp\(|new Phar|Phar::|phar://" src
The SQL injection is reachable only where an application builds PostgreSQL queries with the legacy pg_* escape functions. Code that uses prepared statements and bound parameters does not depend on escaping.
What to do now
- Upgrade to 8.5.9 or 8.4.24. Rebuild your PHP container images, since the runtime ships inside them.
- Search for
pg_escape_*and string concatenated queries. Move them topg_query_paramsor PDO prepared statements. - If you accept user supplied archives, avoid opening them with
phar://.
How this could have been avoided
- Use bound parameters. An escaping flaw cannot hurt a query that never concatenates user input.
- Give the application a least privilege database role. A SQL injection against a role with no DDL or cross schema access does less.
- Do not open untrusted archives as Phar. The Phar fix is about crafted symlinks, and removing the input removes the bug.
Why it matters
Escaping functions are a patch over concatenation. When one has a bug, every application that relied on it inherits the bug at once. Reachability checks answer who: the call to the escape function is the signal, and a code search finds it in minutes.
Quick check
Why does using prepared statements reduce the risk from CVE-2026-17543?
The flaw is in how a string literal is escaped. Prepared statements send values separately from the SQL text, so no escaping step is involved.
