PHP-Sicherheitslücke: Notfall-Patch um 16 Uhr für alle Shops

Die PHP-Sicherheitslücke , die das PHP-Sicherheitsteam am 20. Oktober 2026 angekündigt hat, betrifft nach bisherigem Stand jede Webanwendung ab PHP 5.4 – und damit praktisch jeden Onlineshop in Deutschland. Zwei Schwachstellen, beide mit CVSS v4.0 9,2 bewertet, erlauben nach Angaben von Sicherheitsforschern das Ausführen von Schadcode aus der Ferne, ohne vorherige Anmeldung. Der Patch erscheint heute, 21. Oktober 2026, um 14:00 UTC (16:00 Uhr MESZ). Magento, Shopware und WooCommerce laufen auf PHP; der Fix lässt sich nicht im Shop-Code einspielen, sondern nur auf Server-Ebene. Sansec erwartet Massenangriffe innerhalb von 15 Minuten nach Veröffentlichung.

CVSS 9,2 und kein einziges technisches Detail

Das PHP-Sicherheitsteam veröffentlichte am Abend des 20. Oktober eine Vorankündigung ohne jede technische Information. Bekannt ist nur: zwei kritische Lücken, beide CVSS v4.0 9,2, Release am 21. Oktober um 14:00 UTC. Das Team behält sich vor, früher zu veröffentlichen, sobald Details öffentlich werden oder aktive Ausnutzung nachgewiesen ist. Betroffene Versionen und Fix-Versionen folgen erst mit dem Release.

Die CVE-Nummern CVE-2026-109618 und CVE-2026-109619 stammen nicht aus dem PHP-Advisory, sondern aus einem Leak. Wie BleepingComputer berichtet , bestätigte die Sicherheitsfirma watchTowr, dass es sich um Remote-Code-Execution-Lücken (RCE, Ausführung fremden Codes auf dem Server) handelt und dass sie CVE-2026-109618 bereits nachstellen konnte. Die Ausnutzbarkeit ist damit praktisch belegt. watchTowr spricht von CVSS 10, das PHP-Team von 9,2 – ein Unterschied in der Bewertung, nicht in der Sache.

Vom Hacker-News-Post zum Notfall-Release in 24 Stunden

Die Chronologie nach Sansec : Am 20. Oktober um 15:20 UTC tauchte auf Hacker News ein Post über zwei bevorstehende PHP-RCE-Disclosures auf. Parallel kursierte ein Screenshot eines Exploit-Tools namens PHP2Shell, zugeschrieben einer Gruppe namens Calif.IO. Das Banner des Tools beansprucht Wirksamkeit gegen jede PHP-Version ab 5.4.0. Noch am selben Tag reagierte das PHP-Team mit der Vorankündigung, watchTowr bestätigte den Leak.

Das Embargo ist damit faktisch gebrochen. Wer den Exploit besitzt, hat einen Vorsprung von mindestens 24 Stunden vor dem Patch. CERT-EU reagierte mit Advisory 2026-018 und rät Organisationen, sich auf sofortiges Patchen vorzubereiten. Wo das nicht möglich ist, sollen internetseitige Anwendungen bis zum Fix vom öffentlichen Netz isoliert werden.

„Millionen Websites und Onlineshops“: Dienstleister schlagen Alarm

Inzwischen warnen auch Anbieter außerhalb des Hosting-Geschäfts ihre Händler. Die Rechnungssoftware easybill etwa verschickt eine Alarmmeldung, in der von einer Bedrohung für „möglicherweise Millionen Websites und Onlineshops“ die Rede ist. Betroffen seien praktisch alle PHP-Versionen seit 5.4 – unabhängig davon, ob ein Shop mit WooCommerce, Magento, Shopware, OpenCart oder anderer PHP-Software läuft.

Die Meldung benennt die Folgen konkret: Angreifer könnten ohne Anmeldung fremden Code ausführen, Kundendaten und Datenbanken auslesen, Bestellungen manipulieren, Schadsoftware einschleusen oder ganze Shops übernehmen. Als besonders kritisch gilt, dass die Lücken bekannt wurden, bevor Updates bereitstanden. Die Warnung deckt sich mit der Einschätzung von Sansec und CERT-EU: Sobald technische Details öffentlich sind, folgen automatisierte Massenangriffe.

Magento, Shopware, WooCommerce: Der Fehler liegt unter dem Shop

Die Lücke sitzt im PHP-Interpreter selbst, nicht in einer Shop-Software oder einem Plugin. Sansec stellt klar: Der Angriff greift PHP an, bevor Shop-Code oder Web-Application-Firewalls wie Sansec Shield überhaupt ausgeführt werden. Ein Patch auf Anwendungsebene schützt daher nicht. Die einzige Abhilfe ist ein Update der PHP-Installation auf dem Server – bei Managed Hosting also durch den Hoster.

Offiziell gepflegt werden nur PHP 8.2 und neuer . Server mit PHP 8.1 oder älter erhalten keinen offiziellen Fix. Wer dort noch läuft, ist auf Backports des Hosters oder der Distribution angewiesen – Debian, Ubuntu und RHEL pflegen eigene Pakete, aber ohne Garantie und Zeitplan. Die Alternative ist ein Versionssprung unter Zeitdruck, mit allen Kompatibilitätsrisiken für ältere Shop-Installationen.

15 Minuten nach dem Release beginnt der Scan

Sansec erwartet Massenangriffe innerhalb von 15 Minuten nach Veröffentlichung des Patches. Der Mechanismus ist bekannt: Sobald der Fix öffentlich ist, lässt sich aus dem Code-Diff die Schwachstelle rekonstruieren. Angreifer, die den Exploit bereits besitzen, brauchen nicht einmal das. Die Lücke ist ohne Authentifizierung ausnutzbar, Angriffe lassen sich also vollständig automatisieren und gegen beliebige IP-Bereiche fahren.

Das Zeitfenster zwischen Release und Patch auf dem eigenen Server ist damit die entscheidende Größe. Bei Managed Hosting entscheidet der Hoster über die Länge dieses Fensters. Bei eigenen Servern entscheidet die Vorbereitung: Wer um 16:00 Uhr erst anfängt, Systeme zu inventarisieren, patcht nach den ersten Scans.

Was bis 16 Uhr erledigt sein muss

Erstens: Inventar. Jedes System mit PHP identifizieren – Shop, CMS, Staging, Admin-Tools, interne Dashboards, Cron-Skripte. Die PHP-Version pro System festhalten (php -v oder phpinfo()). Zweitens: Hoster kontaktieren. Bei Managed Hosting heute schriftlich anfragen, wann der Patch eingespielt wird und ob Server mit PHP 8.1 oder älter versorgt werden. Drittens: Update-Pfad vorbereiten. Bei eigenen Servern Paketquellen prüfen, Wartungsfenster blocken, Backup ziehen.

Viertens: Isolationsoption bereithalten. CERT-EU empfiehlt, nicht patchbare internetseitige Systeme vom Netz zu nehmen. Für einen Shop bedeutet das eine Wartungsseite auf Reverse-Proxy- oder CDN-Ebene, nicht in PHP. Fünftens: Nach dem Patch Logs auf ungewöhnliche Requests zwischen 14:00 UTC und Patch-Zeitpunkt prüfen. Ein Server, der in diesem Fenster erreichbar war, gilt bis zum Gegenbeweis als potenziell kompromittiert.

EOL-PHP wird heute zur offenen Flanke

Der Fall legt eine Schwachstelle offen, die nichts mit dem konkreten Bug zu tun hat: PHP-Versionen ohne Support. PHP 7.4 ist seit November 2022 ohne Sicherheitsupdates, PHP 8.0 seit November 2023, PHP 8.1 seit Dezember 2025. Trotzdem laufen ältere Shop-Installationen, Shopware-5- und Magento-1-Reste auf diesen Versionen weiter, weil ein Upgrade Aufwand kostet. Bis heute war das ein abstraktes Risiko.

Mit einer unauthentifizierten RCE gegen alle Versionen ab 5.4 wird daraus ein konkretes: Für diese Systeme gibt es ab 16:00 Uhr einen öffentlich bekannten Angriffsweg und keinen offiziellen Fix. Wer dort personenbezogene Kundendaten verarbeitet, trägt ab diesem Zeitpunkt ein Risiko, das sich nach Art. 32 DSGVO (angemessene technische Maßnahmen) kaum noch begründen lässt. Der Patch von heute schließt zwei Lücken. Die dritte bleibt offen, solange EOL-PHP in Produktion läuft.