John Cuthbert 
PHP’s maintainers released 8.2.33 as a coordinated security update, alongside 8.3.33, 8.4.24, and 8.5.9 — every currently supported branch got the same fixes at the same time. If you’re running any recent PHP version, this is worth ten minutes of attention.
What’s actually being fixed
The headline issue is a SQL injection vulnerability in the PostgreSQL extension (pgsql/pdo_pgsql), tracked as CVE-2026-17543. It affects pg_insert(), pg_update(), pg_select(), and pg_delete() — the escaping these convenience
functions rely on doesn’t fully neutralise backslashes under PostgreSQL’s default standard_conforming_strings setting, which means carefully crafted input can break out of an escaped string and inject SQL. If your stack talks to PostgreSQL through these functions, that’s the one to
prioritise.
Alongside it: a memory-corruption bug in BCMath’s bccomp() when comparing numbers truncated to a caller-supplied scale, a crash triggered by a circular symlink inside a Phar archive, and a backported fix in the bundled libgd image library.
The bigger story
PHP 8.2 itself is now in its final stretch. Active support (new features, non-critical bug fixes) ended back in December 2024 — 8.2 has been security-patches-only since then, and even that runs out on 31 December 2026. That’s under five months away. After that date, any vulnerability found in PHP 8.2 simply doesn’t get fixed, on any host that hasn’t moved off it.
PHP 8.3 is in the same security-only phase, running until December 2027. PHP 8.4 and 8.5 are the two branches currently in full active support — which is where we build everything at Devsigh.
What to do about it
If you’re staying on 8.2 for now, applying 8.2.33 is the non-negotiable part:
# Debian/Ubuntu (via the ondrej/php PPA or your host's package manager)
sudo apt update && sudo apt install php8.2
# Docker
# bump your base image tag, e.g. php:8.2-fpm → php:8.2.33-fpmBut patching 8.2.33 only buys you until the version itself expires. If nobody’s yet had the “when do we move to 8.4” conversation for your stack, five months is enough time to do it properly — on staging, with a real regression pass — and not enough time to leave it much longer.
If patch management and version-upgrade planning keep landing on your desk at the worst possible time, that’s exactly what a Development Retainer is for.
