Was passiert ist

Die beiden Lücken (CVE-2026-109618 und CVE-2026-109619) sind mit CVSS 9.2 bewertet. Beide sitzen in der Request-Verarbeitung von PHP selbst, also vor dem eigenen Anwendungscode. Ein Framework wie Symfony oder Laravel schützt deshalb nicht davor.

• CVE-2026-109618: Wenn PHP während eines Requests der Speicher ausgeht, können interne Daten halb initialisiert bleiben und beim Aufräumen als gültig behandelt werden.
• CVE-2026-109619: Interner Zustand eines Requests kann nach dem Freigeben des Speichers übrig bleiben und vom nächsten Request desselben Workers verwendet werden.

Wer betroffen ist

Jede PHP-Installation, die Web-Requests verarbeitet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt das PHP-Team das Risiko bei mod_php ein. Dort gibt es einen nachgewiesenen Exploit, der ohne Anmeldung funktioniert.

Was du jetzt tun solltest

1. PHP aktualisieren auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Linux-Distributionen und LTS-Anbieter hatten die Patches vorab, die Pakete sollten also bereitstehen.
2. Alle Worker neu starten (PHP-FPM, Apache, FrankenPHP), damit die neue Version tatsächlich läuft. Mit php -v auf der Kommandozeile sieht man nur die CLI-Version, nicht unbedingt die des Webservers.
3. Container-Images neu bauen und ausrollen, auch wenn sich am Code nichts geändert hat.
4. Wer PHP aus rpms.remirepo.net bezieht: Das PHP-Team rät, auf die Pakete der Distribution umzusteigen oder selbst zu bauen, weil das Repository die Updates nicht sofort hatte.

Wenn das Update nicht sofort geht

Das PHP-Team nennt Einstellungen, die einzelne Angriffswege erschweren. Sie machen die Installation ausdrücklich nicht sicher und überbrücken nur die Zeit bis zum Update:

• session.upload_progress.enabled=0 in php.ini oder im FPM-Pool setzen (nicht per ini_set() oder .user.ini) und alle Worker neu starten.
• Unter PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen.
• post_max_size niedrig halten (8M ohne Datei-Uploads, sonst 32M) und Request-Größen schon am Webserver oder Proxy begrenzen.

PHP 8.1 und älter

PHP 8.1 und ältere Versionen bekommen vom PHP-Projekt keine Updates mehr. Wegen der Schwere hat das PHP-Team diesmal trotzdem minimale Patches für 7.4, 8.0 und 8.1 bereitgestellt, allerdings nur als Quellcode zum Selbstbauen. Manche Distributionen und LTS-Anbieter liefern Backports.

Das ist eine Ausnahme, auf die man sich beim nächsten Mal nicht verlassen kann. Spätestens jetzt lohnt sich ein Plan für die Migration auf eine unterstützte Version. Auch PHP 8.2 läuft am 31. Dezember 2026 aus. Welche Versionen noch unterstützt werden, steht auf php.net/supported-versions.php.

Quellen

• php.net: Security advisory vom 21. Oktober 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• php.net: Unterstützte Versionen

Sicherheit: PHP und Symfony aktualisieren

Das Wichtigste zuerst: Für PHP gibt es seit dem 21. Oktober Updates gegen zwei kritische Lücken mit Remote Code Execution (8.5.12, 8.4.27, 8.3.36, 8.2.35). Die Details stehen in einem eigenen Beitrag.

Symfony hat am 15. Oktober drei Lücken veröffentlicht, die einen Prozess mit einem einzigen präparierten Request lahmlegen können:

• HttpFoundation (CVE-2026-108082): Ein präparierter Cache-Control-Header kostet pro Request fast eine Sekunde CPU. Betrifft jede Anwendung, die HTTP-Requests verarbeitet.
• Yaml (CVE-2026-109413): Tief verschachteltes Inline-YAML bringt den Prozess zum Absturz. Betrifft auch #[MapRequestPayload], wenn die Yaml-Komponente installiert ist und das Format nicht eingeschränkt wird.
• ExpressionLanguage (CVE-2026-109449): Tief verschachtelte Ausdrücke bringen den Prozess zum Absturz, zum Beispiel über #[Assert\ExpressionSyntax].

Behoben ist alles in den aktuellen Patch-Versionen 5.4.54, 6.4.48, 7.4.21 und 8.1.9. Ein composer update symfony/* innerhalb der eingesetzten Version reicht.

Support-Enden in den nächsten Monaten

• 30. November 2026: Symfony 6.4 bekommt nur noch Sicherheitsupdates (bis November 2027).
• 31. Dezember 2026: PHP 8.2 bekommt keine Sicherheitsupdates mehr.
• 31. Dezember 2026: PHP 8.4 bekommt nur noch Sicherheitsupdates (bis Ende 2028).
• 31. Januar 2027: Symfony 8.1 läuft aus. Symfony 8.0 ist bereits seit Juli 2026 ohne Support.

Aktuelle Daten stehen auf php.net/supported-versions.php und symfony.com/releases.

Neu im November: PHP 8.6 und Symfony 8.2

PHP 8.6 ist für den 19. November 2026 geplant und steht als Release Candidate zum Testen bereit. Symfony 8.2 folgt Ende November und wird bis Juli 2027 gepflegt. Aus dem Symfony-Blog der letzten Wochen:

• Eine neue JsonSchema-Komponente
• Signierte Messenger-Transports mit Rotation der Secrets
• Unterstützung für HTTP-Trailer
• Sichereres HTML in Übersetzungen

Was das für bestehende Projekte bedeutet

• Läuft das Projekt auf PHP 8.2, ist jetzt der Zeitpunkt für das Update auf 8.3 oder 8.4. Symfony 6.4 und 7.4 laufen auf beiden.
• Symfony 8.0 und 8.1 sind kurzlebige Versionen. Wer darauf sitzt, sollte bis Ende Januar auf 8.2 gehen oder bewusst bei 7.4 LTS bleiben, das bis November 2029 Sicherheitsupdates bekommt.
• Symfony 6.4 ist noch bis November 2027 sicher, aber der Weg auf 7.4 LTS lässt sich jetzt in Ruhe planen. Hilfreich ist, die Deprecations schon unter 6.4 abzuarbeiten.
• PHP 8.6 muss niemand sofort einsetzen. Es lohnt sich aber, die CI um einen Lauf mit 8.6 zu ergänzen, um Deprecations früh zu sehen.

Quellen

• php.net: News
• Symfony: Security Advisories
• Symfony: Releases und Support-Zeiträume
• PHP 8.6: Release-Plan
• Symfony-Blog: New in Symfony 8.2