PHP patches a PostgreSQL SQL injection: CVE-2026-17543 and four branches updated at once

Four branches patched on the same day: that tells you something

On 30 July PHP shipped 8.5.9, 8.4.24, 8.3.33 and 8.2.33 — all four at once, all four tagged as a security release. When the PHP team pushes the same batch simultaneously across every supported branch, it isn't for fun: the flaw sits in shared code and reaches all the way back to the oldest version they still maintain.

Three weeks ago we wrote about 8.5.8 and 8.4.23, and that was a quiet round. This one has real meat: there's an SQL injection CVE. That said, before anyone panics, the honest answer to "does this hit me?" depends a lot on which database you run.

In one sentence

Five CVEs get closed: an SQL injection in the pgsql extension (CVE-2026-17543), an out-of-bounds write in BCMath's bccomp() (CVE-2026-17544), the memory corruption in openssl_encrypt we already knew about, finally landing on the 8.5 branch (CVE-2026-14355), a Phar crash via recursive symlinks (CVE-2026-7260) and a libgd upgrade (CVE-2026-9672). Thrown in for free: four memory bugs in PDO_ODBC with no CVE assigned.

If you work with PostgreSQL, stop reading, update, come back. If you're on MySQL or MariaDB — most people — the headline doesn't apply to you, but BCMath probably does.

The flaws, ordered by what you should look at first

1. SQL injection in pgsql (CVE-2026-17543)

This is the headline of the batch. The security advisory describes it as an SQL injection via E'...' backslash breakout.

In plain terms: PostgreSQL has a special kind of string literal, the one written E'text', where the backslash is treated as an escape character rather than an ordinary character. PHP's escaping wasn't accounting for that properly, so a crafted input could break out of the quotes and smuggle its own SQL into the query.

It hits you if your application talks to PostgreSQL through the pgsql extension and builds queries by escaping values rather than using genuinely parameterised prepared statements. If you do use real prepared statements — $1, $2 parameters, not concatenation in disguise — the attack gets a lot harder, but update anyway: auditing every corner of your codebase to save yourself one apt install is a bad trade.

2. Out-of-bounds write in bccomp() (CVE-2026-17544)

BCMath is the arbitrary-precision arithmetic extension, the one you use so floating-point decimals don't quietly eat your cents. Which means anything handling money seriously pushes numbers through it. bccomp() compares two of those numbers, and this patch closes an out-of-bounds write in it.

This is the one that touches the most shops and billing systems we manage, and it's why this round isn't optional even if you never go near PostgreSQL.

3. openssl_encrypt with AES-WRAP-PAD: the one we've been carrying (CVE-2026-14355)

We covered this one on 6 July, when it was fixed in 8.4.23. What we didn't say back then — because nobody knew — is that the 8.5 branch was left out of that patch. It's fixed now, in 8.5.9, and it finally has a CVE number.

The lesson is worth more than the bug itself: a newer branch does not automatically mean a better-patched one. If you moved to 8.5.8 in July thinking you were ahead of whoever was sitting on 8.4.23, on this specific flaw you were behind. It's still an uncommon cipher mode (key wrapping, not everyday encryption), so most setups never trigger it.

4. Phar recursive symlinks (CVE-2026-7260) and libgd (CVE-2026-9672)

The two closers. The Phar one causes a crash via recursive symlinks: the process dies, no code execution. It matters if you manipulate .phar archives or load code packaged in that format. The libgd one arrives through an upgrade of the library sitting under the GD extension — the one half the internet and every CMS uses to resize user-uploaded images. If your site lets people upload photos, you are running that code.

5. PDO_ODBC: four memory bugs, no CVE

No CVE numbers, but they don't read well: a heap buffer over-read when a column value exceeds the driver-reported display size, a heap buffer overflow when an output parameter is longer than its declared maxlen, an out-of-bounds write when the driver reports a diagnostic message longer than the error buffer, and a crash with connection pooling when the DSN carries no credentials.

On a typical web server you never come near any of this. If you have PHP talking over ODBC to a SQL Server or a legacy AS/400, you already know you do — and these four are yours.

Who's affected

• High priority: anyone on PostgreSQL using the pgsql extension (CVE-2026-17543), and anyone moving money through BCMath (CVE-2026-17544).
• Medium priority: anyone on the 8.5 branch using openssl_encrypt for key wrapping — the patch 8.4 got three weeks ago and 8.5 didn't — and any site accepting image uploads (libgd).
• Specific cases: applications that manipulate Phar archives and those connecting over ODBC.
• Everyone else: there's no exploit loose on the internet aiming at your server this week, but that's four branches patched on the same day and a ten-minute update. There's no sensible excuse for pushing it to September.

What to do today

1. Check which version you have

php -v

Targets, by branch:

2. Check whether the big one applies to you

# Is the PostgreSQL extension loaded?
php -m | grep -i pgsql

# What about BCMath?
php -m | grep -i bcmath

If the first one returns anything, the SQL injection is your problem and this just became urgent.

3. Update and reload PHP-FPM (no downtime)

# Debian / Ubuntu (Ondřej Surý's repository)
sudo apt update && sudo apt install --only-upgrade php8.5 php8.5-fpm
sudo systemctl reload php8.5-fpm

# RHEL / AlmaLinux / Rocky (Remi repository)
sudo dnf update php php-fpm
sudo systemctl reload php-fpm

Reloading PHP-FPM swaps in the new binary without cutting in-flight requests. Adjust the version number (php8.5, php8.4…) to whatever you have installed.

4. Confirm it stuck

php -v
php-fpm8.5 -v   # or php-fpm -v depending on your distro

As always with distributions: sometimes they backport the fix while keeping a different version number. Don't trust the number alone, check the package date or your distro's security changelog. "It's updated" is something you verify, not something you remember.

What we do

When a batch like this lands, the first move isn't to update everything blindly — it's to cross-reference the flaw against what's actually installed. We pull out which servers have pgsql loaded, which ones expose an internet-facing application and which ones have billing running through BCMath, and those go first, today. The rest joins the normal update round for the week.

That list — which extensions each server loads, which version it runs, when it was last patched — is what turns a five-CVE batch into a ten-minute chore instead of an afternoon of surprises. Keeping it current is worth more than chasing every point release.

The same old routine

• php -v to know where you stand.
• php -m to know which extensions you actually load.
• apt/dnf update of PHP and PHP-FPM.
• systemctl reload php*-fpm.
• php -v again to confirm.

If your PHP hasn't seen a patch in months, or you're not sure which extensions each server you manage is loading, this is a good moment to check. And if you'd rather we handled it, let's talk.

References

• PHP.net — ChangeLog for the 8 branch
• PHP.net — Downloads
• GHSA-7qpv-r5mr-78m4 — SQL injection in pgsql
• GHSA-x692-q9x7-8c3f — Out-of-bounds write in bccomp()
• GHSA-vc5h-9ppw-p5f3 — Phar crash via recursive symlinks