PHP-Notfallrelease ist da: Erste Angriffe laufen bereits
Das PHP-Notfallupdate ist seit 16:00 MESZ da, behebt zwei Lücken im PHP-Kern selbst. Es wurden bereits erste Angriffsversuche beaobachtet. Auch für PHP 8.1 und älter gibt es von einzelnen Anbietern Patches. Konfigurationsänderungen oder eine WAF allein schützen laut PHP-Entwicklern nicht.
Technology
Berlin, 21. Oktober 2026. Um 16:00 MESZ hat das PHP-Entwicklerteam wie angekündigt sein Notfall-Sicherheitsupdate veröffentlicht. Es schließt die beiden kritischen Schwachstellen CVE-2026-109618 und CVE-2026-109619 (CVSS 9,2), über die wir bereits am Vormittag berichtet hatten. Inzwischen liegen deutlich mehr gesicherte Informationen vor – und einige davon sind weniger beruhigend, als zu hoffen war.
Was jetzt bekannt ist
- Ursache: Beide Schwachstellen liegen im PHP-Kern selbst, nicht in einer Anwendung oder einem Plugin. CVE-2026-109618 betrifft den Umgang mit Out-of-Memory-Situationen: Wird PHP während einer Anfrage unterbrochen, während interne Request-Daten nur teilweise initialisiert sind, kann die anschließende Bereinigung diese unvollständigen Daten fälschlich als gültig behandeln. CVE-2026-109619 betrifft internen Zustand, der eigentlich zu einer einzelnen Anfrage gehört, aber in bestimmten Fällen über das Freigeben des zugehörigen Speichers hinaus bestehen bleibt – eine nachfolgende Anfrage auf demselben Worker kann auf diesen veralteten Zustand zugreifen, bevor er zurückgesetzt wird.
- Betroffene Betriebsarten: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. mod_php-Setups gelten als besonders gefährdet.
- Gefixte Versionen: PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12.
- PHP 8.1 und älter: Eine wichtige Präzisierung gegenüber unserem ersten Artikel: Einzelne Anbieter, bieten auch Patches für ältere Versionen an. Dennoch sollte ein Update nicht weiter aufgeschoben werden.
- Angriffslage: Cloudflare berichtet, bereits erste Angriffsversuche zu beobachten. Exploit-Code zirkuliert öffentlich. Das Zeitfenster zwischen Veröffentlichung des Patches und aktiver Ausnutzung war, wie von Sansec erwartet, extrem kurz.
Konfigurationsänderungen helfen hier nicht
Ein PHP-Core-Entwickler (Gina Peter Banyard) hat es unmissverständlich formuliert: Die einzige wirksame Maßnahme ist das Einspielen des Updates beziehungsweise ein Versionsupgrade. Naheliegende Konfigurationsanpassungen, etwa das Deaktivieren von session.upload_progress, wurden von PHP-Seite ausdrücklich als wirkungslos eingestuft. Das bestätigt die Einschätzung aus unserem ersten Artikel: Auch eine WAF kann hier allenfalls ergänzen, aber keine Lücke im PHP-Interpreter selbst schließen. Erste Anbieter haben zwar WAF-Regeln für bekannte Angriffsmuster ausgerollt, diese decken jedoch nur den Traffic ab, der tatsächlich über die jeweilige WAF läuft, und ersetzen in keinem Fall das Update.
Handlungsempfehlung
-
PHP 8.2 oder neuer:
Das verfügbare Update umgehend einspielen, sofern noch nicht geschehen.
-
PHP 8.1 oder älter:
Beim Hosting- oder Distributions-Anbieter aktiv nachfragen, ob ein Patch bereitsteht oder geplant ist.
-
Keine falsche Sicherheit durch Konfigurationsänderungen.
Die naheliegenden Workarounds bieten laut PHP-Entwicklern keinen verlässlichen Schutz.
-
WAF-Regeln als Überbrückung verstehen, nicht als Ersatz.
Sie können helfen, die Zeit bis zum Patch zu überbrücken, lösen aber nicht das zugrunde liegende Problem.
Was bedeutet das für ScaleCommerce-Kunden?
Unsere Entwickler haben die Lage seit dem Bekanntwerden der Schwachstelle im Griff: Den ganzen Tag über wurden die notwendigen Updates auf den betroffenen Systemen vorbereitet und eingespielt. ScaleCommerce kümmert sich darum, dass alle Kundinnen und Kunden bestmöglich geschützt sind, und meldet sich aktiv bei allen, bei denen zusätzlicher Handlungsbedarf besteht. Dennoch empfehlen wir allen Betreiberinnen und Betreibern, zur Sicherheit auch selbst noch einmal einen Blick auf das eigene System zu werfen.