PHP 8.4.21 und 8.3.31: Wenn das Null-Byte zur SQL-Schleuse wird — was die Mai-Sammelpatches für TYPO3- und Sylius-Stacks bedeuten

Zusammenfassung in 90 Sekunden

Am 7. Mai 2026 hat das PHP-Team die koordinierte Sicherheits-Sammelfreigabe für PHP 8.2.31, 8.3.31, 8.4.21 und 8.5.6 ausgespielt. Jede Linie schließt zwischen acht und dreizehn Schwachstellen — in FPM, mbstring, SOAP, OpenSSL-4.0-Anbindung und der Standard-Library. Die diskussionswürdigste Position sitzt im PDO-Firebird-Treiber: NUL-Bytes in zitierten Strings werden falsch behandelt, sodass Eingaben hinter dem Null-Zeichen verloren gehen — und mit ihnen die gesamte Sanitisierung. SQL-Injection trotz Prepared Statements, dokumentiert als GHSA-w476-322c-wpvm und CVE-2025-14179.

Wer einen TYPO3- oder Sylius-Stack betreibt, hat die PHP-8.2-, 8.3- oder 8.4-Linie unter sich. Alle Linien haben heute Patches verfügbar — reine Patch-Level-Updates ohne API-Brüche. Wirkungsklasse: SQL-Injection auf PDO-Firebird, dazu Memory-Lecks, Use-after-free in SOAP, Null-Pointer-Dereference in mbstring, XSS im FPM-Status-Endpunkt. Im DACH-Mittelstand betrifft das jeden CMS- und Shop-Host — unabhängig davon, ob Firebird im Stack ist oder nicht, weil die mbstring-, SOAP- und FPM-Korrekturen in jeder Request-Bahn liegen.

Was am 7. Mai gepatcht wurde — und wo die Lücke richtig sitzt

Die Mai-Welle ist breiter als der typische PHP-Sicherheits-Punkt-Release. Allein PHP 8.3.31 hebt mehrere Klassen auf einmal an: einen XSS-Vektor im FPM-Status-Endpunkt, einen Null-Pointer-Dereference in php_mb_check_encoding(), OpenSSL-4.0-Kompatibilität, mehrere SOAP-Korrekturen rund um stale pointers und Use-after-free — und die genannte SQL-Injection in PDO-Firebird via NUL-Byte. PHP 8.4.21 zieht Memory-Lecks in Session- und Phar-Handling sowie eine JIT-Assertion-Fehlerstelle nach. PHP 8.2.31 als End-of-Life-naher LTS-Stand bekommt die kritischen Korrekturen ebenfalls; PHP 8.5.6 rollt die Linie parallel mit.

Die Firebird-Lücke (GHSA-w476-322c-wpvm, vergeben als CVE-2025-14179) ist die strukturell interessanteste Position. Der Treiber stoppt seine Eingabevalidierung am ersten NUL-Byte; der String dahinter wird vom Query-Parser dann doch verarbeitet. Wer Eingaben validiert, bevor sie in den PDO-Prepared-Statement-Pfad laufen, hat die Lücke häufig nicht im Blick — die Annahme „Prepared Statements + PDO = sicher“ hält in diesem Spezialfall nicht.

Warum „wir nutzen Firebird gar nicht“ zu kurz greift

Wer Firebird produktiv nicht einsetzt, ist von dieser einen Lücke nicht direkt betroffen. Die Mai-Sammelfreigabe enthält aber mehr — und sie zeigt strukturell etwas, das wir in Reviews regelmäßig sehen: PHP-Sicherheits-Punkt-Releases werden nicht unmittelbar eingespielt, weil „uns betrifft das nicht“. Diese Logik bricht spätestens dann, wenn die nächste Welle in einer Komponente landet, die genutzt wird — SOAP, OpenSSL, mbstring, FPM stehen alle in der Mai-Welle drin und sind in jeder TYPO3- oder Sylius-Anwendung präsent.

Die Patch-Disziplin in PHP-Lehre ist nicht „kritische Lücken sofort, der Rest später“. Sie lautet: innerhalb der Punkt-Release-Linie immer auf den jüngsten Patch. Wer auf 8.3.30 stehen bleibt, weil die Firebird-Lücke „nicht uns“ sei, hat den XSS im FPM-Status, den SOAP-Speicherfehler und die mbstring-Dereference unverändert in der Produktion.

Was wir konkret empfehlen

Erstens — und am unmittelbarsten: Heben Sie Ihre PHP-Linie auf den 7.-Mai-Stand. Für 8.3 ist das 8.3.31, für 8.4 ist das 8.4.21, für 8.2 (sofern noch im Bestand) 8.2.31. Beide Sprünge sind reine Patch-Level-Updates, keine API-Brüche. In typischen TYPO3-13.4-LTS-Setups ist das Update mit php -v lesbar, in composer.json über die "require": { "php": ">=8.3" }-Spannweite tragbar. Sylius- und Symfony-Projekte folgen demselben Pfad.

Zweitens — und für Multi-Shop- und Multi-Mandanten-Häuser besonders relevant: Prüfen Sie, ob Ihr CI/CD den Punkt-Release-Sprung automatisch nachzieht. Wir sehen häufig Pipelines, die PHP-Versionen pinnen (php:8.3.30-fpm-alpine) und dabei vergessen, die Tags regelmäßig zu rotieren. Wolfi-OS-Images werden täglich neu gebaut und ziehen den Patch automatisch — proprietäre Alpine- oder Debian-basierte Images tun das nicht ohne Refresh-Job in der Pipeline.

Drittens — die strukturelle Frage hinter der Firebird-Lücke: Wo in Ihrem Code-Pfad gehen User-Strings durch eine Quoting-Schicht, die kein End-of-String erwartet? Das Muster „NUL-Byte stoppt Validierung“ ist nicht spezifisch für PDO-Firebird; es taucht in C-Bindings, alten Wrapper-Libraries und gelegentlich in selbstgebauten Sanitizern auf. Eine kurze Code-Suche nach \0 und chr(0) in den eigenen Repositorys ist heute die drei Minuten wert.

Was wir bewusst nicht empfehlen

Wir empfehlen nicht, die Mai-Welle zum Anlass zu nehmen, eine PHP-Major-Migration anzustoßen. PHP 8.5 ist seit November 2025 verfügbar; wer auf 8.3 LTS sitzt, hat Support bis Dezember 2027. Der Sprung 8.3 → 8.4 oder 8.4 → 8.5 ist eine eigene Architekturentscheidung mit eigenem Test-Aufwand, kein Patch-Tuesday-Reflex.

Wir empfehlen ebenso wenig, sich auf vorgelagerte WAF-Filter zu verlassen, die NUL-Bytes in URL-Parametern abfangen. Das ist eine sinnvolle Verteidigung in der Tiefe, aber kein Ersatz für den Patch — wer den Treiber im PHP-Prozess hält, hält die Lücke.

Was wir konkret getan haben

Bei Moselwal selbst ist die Mai-Welle durch. Wir betreiben unsere TYPO3-, Sylius- und Symfony-Stacks, wo es die Mandantenkonfiguration zulässt, auf PHP 8.5; die Wolfi-OS-Images ziehen die regulären Punkt-Releases im täglichen Rebuild automatisch nach. Für Mandanten auf 8.3 LTS oder 8.4 ist der Sprung auf 8.3.31 bzw. 8.4.21 in der laufenden Wartungsbahn eingetragen und wird im nächsten regulären Patch-Sprint eingespielt: Lockfile-Refresh, Image-Tag-Rotation, Smoke-Tests gegen die Mandanten-Frontends.

Dass die Welle bei uns nicht aufschlägt, ist keine Glanzleistung. Es ist das erwartbare Verhalten einer Pipeline, die wir entsprechend gebaut haben: tägliche Wolfi-Rebuilds, gepinnte Image-Tags mit Refresh-Job, automatisierte composer.lock-Diffs gegen die jeweilige Major-Linie. Was als „bei uns durch“ liest, ist drei Jahre Pipeline-Hygiene mit klaren Verantwortlichkeiten.

Wer am stärksten betroffen ist

TYPO3-Häuser mit langer Dienstgeschichte, die auf 8.3 oder 8.4 stehen und ihre PHP-Patches aus historischen Gründen quartalsweise einspielen. Diese Stacks haben SOAP- und mbstring-Pfade in jedem Frontend-Request — die heutige Welle adressiert sie alle und gehört in den Mai-Patch-Sprint, nicht in den Quartalsplan.

Sylius-Multimandanten-Häuser, die ihre Shops aus einem gemeinsamen Composer-Lockfile heraus aktualisieren. Hier reicht ein Lockfile-Refresh nicht — die PHP-Engine selbst muss auf den 7.-Mai-Stand. Wer Shops in unterschiedlichen Container-Hosts laufen lässt, prüft heute, ob alle Hosts die neue Image-Tag rollen.

KMU mit Eigenentwicklung auf Symfony, die ihre Production-Container aus älteren Alpine-Images bauen. Diese Images werden bei vielen CI-Pipelines mit :latest referenziert, aber das :latest-Tag wird nicht automatisch neu gebaut — wer keinen Image-Refresh-Job hat, sitzt auf dem Vor-Mai-Stand und merkt es nicht.

Fazit

Die Mai-Welle ist keine Sensation. Sie ist eine Routine-Pflicht — und sie ist die Art von Pflicht, an der man die operative Reife eines PHP-Stacks ablesen kann. Wer heute noch auf 8.3.30 oder 8.4.20 sitzt, hat keinen technischen Grund mehr, sondern eine offene Aufgabe. Die Firebird-Lücke ist der laute Aufhänger; die mbstring-, SOAP- und FPM-Korrekturen sind die strukturell wichtigeren Stellen.

Die Frage lautet nicht, ob die Mai-Welle Sie betrifft. Sie lautet, ob Ihre Pipeline so gebaut ist, dass sie Punkt-Releases ohne Eskalation nachzieht — oder ob jemand sie heute manuell anschieben muss.