PHP 8.4.21 and 8.3.31: When the null byte becomes a SQL gateway — what the May roll-up means for TYPO3 and Sylius stacks

The 90-second summary

On 7 May 2026 the PHP team shipped the coordinated security roll-up for PHP 8.2.31, 8.3.31, 8.4.21 and 8.5.6. Each line closes between eight and thirteen vulnerabilities — in FPM, mbstring, SOAP, OpenSSL 4.0 wiring and the standard library. The most interesting item lives in the PDO Firebird driver: NUL bytes inside quoted strings are mis-handled, so anything after the null character is silently dropped from validation — and arrives at the parser unsanitised. SQL injection despite prepared statements, documented as GHSA-w476-322c-wpvm and CVE-2025-14179.

Anyone running a TYPO3 or Sylius stack has the PHP 8.2, 8.3 or 8.4 line under it. All lines have patches available today — plain patch-level updates with no API breaks. Impact class: SQL injection on PDO Firebird, plus memory leaks, use-after-free in SOAP, null-pointer dereference in mbstring, XSS in the FPM status endpoint. For DACH mid-market, the wave touches every CMS and shop host, with or without Firebird in the stack — because the mbstring, SOAP and FPM fixes sit in every request path.

What was patched on 7 May — and where the real hole sits

The May wave is broader than a typical PHP security point release. PHP 8.3.31 alone lifts several classes at once: an XSS vector in the FPM status endpoint, a null-pointer dereference in php_mb_check_encoding(), OpenSSL 4.0 compatibility, several SOAP corrections around stale pointers and use-after-free — and the NUL-byte SQL injection in PDO Firebird. PHP 8.4.21 follows with memory leak fixes in session and Phar handling and a JIT assertion failure. PHP 8.2.31, near end of life as an LTS-style line, picks up the critical fixes as well; PHP 8.5.6 rolls alongside.

The Firebird issue (GHSA-w476-322c-wpvm, tracked as CVE-2025-14179) is the structurally most interesting position. The driver stops its input validation at the first NUL byte, while the query parser then keeps processing whatever follows. Anyone validating input before it reaches the PDO prepared-statement path will often miss this case — the assumption “prepared statements + PDO = safe” does not hold here.

Why “we don’t use Firebird” falls short

If Firebird is not in production, that one vulnerability does not bite. But the May roll-up contains more — and it reveals something we see repeatedly in reviews: PHP security point releases get deferred because “it doesn’t apply to us”. That logic breaks the moment the next wave lands in a component you do use — SOAP, OpenSSL, mbstring, FPM are all in the May wave and live inside every TYPO3 or Sylius application.

The PHP patch discipline is not “critical bugs immediately, the rest later”. It reads: within a point-release line, always run the most recent patch. Whoever stays on 8.3.30 because the Firebird item “isn’t us” keeps the FPM status XSS, the SOAP memory error and the mbstring dereference in production unchanged.

What we concretely recommend

First — and most directly: lift your PHP line to the 7 May floor. For 8.3 that is 8.3.31, for 8.4 it is 8.4.21, for 8.2 (if still in scope) 8.2.31. All jumps are pure patch-level updates without API breaks. In a typical TYPO3 13.4 LTS setup the update is visible with php -v and stays inside the "require": { "php": ">=8.3" } range in composer.json. Sylius and Symfony projects follow the same path.

Second — especially relevant for multi-shop and multi-tenant houses: check whether your CI/CD picks the point-release jump up automatically. We frequently see pipelines that pin PHP versions (php:8.3.30-fpm-alpine) and forget to rotate the tag. Wolfi OS images get rebuilt daily and pull the patch in automatically — proprietary Alpine- or Debian-based images do not, without a refresh job in the pipeline.

Third — the structural question behind the Firebird item: where in your code path do user strings pass through a quoting layer that does not expect end-of-string? The “NUL byte stops validation” pattern is not specific to PDO Firebird; it surfaces in C bindings, in older wrapper libraries and occasionally in home-grown sanitisers. A short code search for \0 and chr(0) in your own repositories is three minutes well spent today.

What we deliberately do not recommend

We do not recommend taking the May wave as a trigger for a PHP major migration. PHP 8.5 has been available since November 2025; anyone on 8.3 LTS has support until December 2027. The jump 8.3 → 8.4 or 8.4 → 8.5 is a separate architecture decision with its own test budget — not a patch-Tuesday reflex.

Equally, we do not recommend leaning on an upstream WAF filter that drops NUL bytes in URL parameters. That is reasonable defence in depth, but no substitute for the patch — whoever keeps the driver in the PHP process keeps the vulnerability.

What we have actually done

In our own operations the May wave is already through. Wherever the customer configuration allows it, we run TYPO3, Sylius and Symfony stacks on PHP 8.5; the Wolfi OS images pull regular point releases in a daily rebuild. For clients on 8.3 LTS or 8.4, the jump to 8.3.31 or 8.4.21 is on the running maintenance line and will be rolled out in the next regular patch sprint: lockfile refresh, image tag rotation, smoke tests against the client frontends.

That the wave does not land on us is not a feat. It is the expected behaviour of a pipeline built for exactly that: daily Wolfi rebuilds, pinned image tags with a refresh job, automated composer.lock diffs against each major line. What reads as “we are through” is three years of pipeline hygiene with clear ownership.

Who is most exposed

TYPO3 houses with long service history, sitting on 8.3 or 8.4, who roll PHP patches on a quarterly cadence for historical reasons. These stacks have SOAP and mbstring paths in every frontend request — the May wave touches all of them and belongs in the May sprint, not the next quarter.

Sylius multi-tenant houses updating their shops from a shared Composer lockfile. A lockfile refresh is not enough here — the PHP engine itself has to reach the 7 May floor. If shops run on different container hosts, check today that every host has rotated to the new image tag.

SMEs with in-house Symfony that build their production containers from older Alpine images. Those images are often referenced as :latest in CI, but :latest does not get rebuilt automatically — without an image refresh job, the pre-May state sits in production and no one notices.

Verdict

The May wave is not a headline event. It is a routine duty — and the kind of duty against which the operational maturity of a PHP stack can be read. Anyone still on 8.3.30 or 8.4.20 today has no longer a technical reason but an open task. The Firebird vulnerability is the loud hook; the mbstring, SOAP and FPM corrections are the structurally more important pieces.

The question is not whether the May wave touches you. It is whether your pipeline is built to pull point releases without escalation — or whether someone has to push it manually today.