PHP-Sicherheitslücke: Noch immer Störungen – das zählt jetzt

Die PHP-Sicherheitslücke (Wortfilter berichtete hier ) ist seit dem 21. Oktober 2026, 16:00 Uhr, offiziell geschlossen – und trotzdem sind am zweiten Tag danach Shops, ERP-Systeme und Hosting-Oberflächen gestört. Gambio hat mehrere Dienste offline genommen, DreamRobot ist nicht erreichbar (Stand 10:00 Uhr), bei Host Europe, DomainFactory und Alfahosting laufen die Wartungen noch. Gleichzeitig kursieren widersprüchliche Angaben zu CVSS-Wert, betroffenen Versionen und Workarounds. Dieser Beitrag ordnet ein, was passiert ist, warum so viele Seiten nach dem Patch offline gingen und welche Hoster und Systeme Stand Donnerstagvormittag (10:00 Uhr) gepatcht sind. Wortfilter hat außerdem die großen Marktplätze gefragt, ob sie die Bewertung der Serviceleistungen für den Ausfallzeitraum aussetzen.

Zwei Lücken, 423 geänderte Dateien, kein vollständiger Workaround

Das PHP-Projekt hat am 21. Oktober um 14:00 UTC die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei Schwachstellen im PHP-Kern, beide mit CVSS v4.0 9,2 bewertet: CVE-2026-109618 (ein Speicherfehler bei Out-of-Memory, der interne Request-Daten halbfertig zurücklässt) und CVE-2026-109619 (Request-Zustand überlebt im Worker und wird vom nächsten Request wiederverwendet). Beide erlauben das Ausführen von Code ohne Anmeldung, bevor Shop-Code überhaupt läuft. Betroffen sind laut Advisory PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed – also jede Konfiguration, die Webanfragen bedient.

Der Fix ändert nach Angaben von Bitpage 423 Dateien. Das PHP-Team schreibt ausdrücklich, dass es keinen vollständigen Workaround gibt: memory_limit=-1, ein niedriges post_max_size und session.upload_progress.enabled=0 verkleinern nur die Angriffsfläche. Sie müssen in der php.ini oder im FPM-Pool gesetzt werden, nicht per ini_set() oder .user.ini. Ein Wartungsmodus im Shop-Backend schützt nicht, weil PHP die Anfrage trotzdem verarbeitet – das bestätigen JTL und WordPress.org unabhängig voneinander. Wortfilter hatte die Lücke am Dienstagmorgen vor dem Patch eingeordnet.

CVSS 10 oder 9,2? Warum selbst Fachleute durcheinanderkommen

Die Verwirrung hat einen Grund: Das Embargo brach am 20. Oktober an mehreren Stellen gleichzeitig. Ein anonymer Post auf Hacker News, Screenshots eines Exploit-Tools namens „PHP2Shell“ und ein kurzes Video kursierten auf X und Mastodon, bevor das PHP-Team überhaupt eine Ankündigung veröffentlicht hatte. Die Sicherheitsfirma watchTowr bestätigte die Lücken öffentlich samt beider CVE-Nummern. PHP zog den Release daraufhin um einen Tag vor – Ubuntu bestätigt , dass die Offenlegung ursprünglich für den 22. Oktober geplant war.

Alexandre Daubois aus dem PHP-Security-Team hat die wichtigsten Falschangaben aufgelistet : Florian Roth und watchTowr nannten CVSS 10,0, PHP selbst 9,2. Sansec schrieb „PHP 5.4 oder neuer“, watchTowr „Version 5 bis 8″ – inklusive einer PHP 6, die nie erschienen ist. Der meistgeteilte Workaround session.upload_progress.enabled=Off gehört nur zu CVE-2026-109619 und hilft gegen die erste Lücke gar nicht. Und den vom Advisory vorrangig empfohlenen Notbehelf (memory_limit=-1) nannte zunächst kein einziges Write-up. Wer am Dienstag drei Fachartikel las, bekam drei verschiedene Versionen der Wahrheit.

Dazu kommt ein Nummernproblem: Distributionen wie Ubuntu und Debian liefern den Fix als Backport, ohne die Versionsnummer zu ändern. Ubuntu 24.04 bleibt bei „8.3.6″, Plesk-Builds für PHP 7.4 bis 8.1 behalten ihre alte Nummer. Ein php -v sagt also nichts darüber, ob der Server gepatcht ist – entscheidend ist der Paketstring oder das Build-Datum. Auf dem Sellerforum kursierte am Abend zudem die Behauptung, die Lücke funktioniere „noch auf 8.5.12″. Die verlinkte Quelle bezieht sich auf einen anderen Fund, nicht auf die beiden gepatchten CVEs.

Warum der Patch da ist und Seiten trotzdem offline bleiben

Die Ausfälle haben vier Ursachen, und nur eine davon ist der Patch selbst. Erstens haben viele Hoster ihre Systeme vorsorglich abgeschaltet, weil der Exploit vor dem Fix im Umlauf war: Mittwald fuhr um 16:17 Uhr alle Systeme herunter, netcup nahm Webhosting und Managed Server ab 16:25 Uhr vom Netz, Timme Hosting deaktivierte alle Websites wegen aktiver Ausnutzung, Uberspace schaltete PHP komplett ab. Cloudflare-Chef Matthew Prince beschrieb den Verlauf der Angriffsversuche: tausende vor der Ankündigung, zehntausende 45 Minuten danach, Millionen am Mittwoch.

Zweitens gibt es für PHP 8.1 und älter kein offizielles Release, nur Backport-Branches zum Selbstbauen. Jeder Hoster muss diese Versionen selbst kompilieren und testen. Profihost meldete am Donnerstag um 8:49 Uhr, dass PHP 7.4 bis 8.1 noch in der Testphase sind und 5.6 bis 7.3 angepasst werden. Hetzner brauchte bis Donnerstag 6:32 Uhr für PHP 5.6 und 7.3. Wer einen alten Shop auf PHP 7.4 betreibt, wartet also auf einen Patch, den es offiziell gar nicht gibt.

Drittens hängen Verwaltungsoberflächen an eigenen Produkten: netcups Control Panel blieb bis zu einem separaten Plesk-Update um 4:09 Uhr offline, Alfahosting meldet gestörte CloudPit-Logins, all-inkl gab das KAS erst schrittweise frei. Viertens laufen Container und Docker-Images: Plenty, Nextcloud und viele Agenturen mussten Images neu bauen und Container neu erstellen, ein Update im laufenden Betrieb reicht dort nicht. Bei Rocky Linux, Oracle Linux, Alpine und dem Remi-Repository fehlten am Donnerstagmorgen laut Digital Applied noch Pakete; Amazon Linux 2 steht auf „No Fix Planned“.

Gambio offline, DreamRobot nicht erreichbar, Plenty und JTL durch

Gambio meldet auf seiner Statusseite ohne Zeitstempel, dass Cloud Portal, Module Store, Payment Hub, Kundenportal, Blog und Forum vorsorglich offline sind. Eine Aussage zu den Shops selbst, zur Dauer oder zum Patch-Stand fehlt; der Support ist nur per Mail erreichbar. DreamRobot war am Donnerstagvormittag weiterhin nicht erreichbar: Die Website zeigt eine Wartungsseite, die Anwendung antwortet nicht, eine öffentliche Stellungnahme gibt es nicht. Händler mit DreamRobot-Anbindung können damit seit Mittwoch keine Bestellungen abrufen und keine Versandbestätigungen an Amazon und eBay zurückmelden.

„Wir haben auf die weltweite PHP-Sicherheitslücke frühzeitig reagiert und die notwendigen Maßnahmen unmittelbar eingeleitet.

Um die Sicherheit unserer Händler und ihrer Daten zu gewährleisten, haben wir die Plattform vorsorglich vorübergehend offline genommen. Die Wiederherstellung war dabei auch von externen Plattformdiensten und unserem Hoster abhängig.

Unser Team hat mit höchster Priorität daran gearbeitet, die Systeme schnellstmöglich und vor allem sicher wieder hochzufahren. Seit heute Morgen um 10 Uhr ist DreamRobot wieder erreichbar.

Uns ist bewusst, wie wichtig die Verfügbarkeit unserer Plattform für unsere Händler ist, und wir bedauern die entstandenen Einschränkungen sehr. Die Sicherheit und Stabilität unserer Plattform haben für uns oberste Priorität.

Bei Fragen können sich unsere Kunden jederzeit direkt an [email protected] wenden.“, so Co-CEO Friedhelm Tauber von der EC1 Gruppe zu der auch DreamRobot gehört.

JTL hat im Forum um 17:08 Uhr gemeldet, dass alle bei JTL gehosteten Shops gepatcht sind. Betroffen sind Shop 5, der WooCommerce-Connector und der PrestaShop-Connector; die Wawi nutzt kein PHP. Selbst gehostete Shops müssen die PHP-Version wechseln, für 8.1 und älter gibt es keinen Patch. JTL warnt zudem vor Phishing-Mails mit angeblichen Patch-Dateien. plentyONE hat laut einer im Community-Forum zitierten Kundenantwort die gepatchten Docker-Images nach dem Release eingespielt, Kunden müssten nichts tun. Eine offizielle Statusmeldung dazu gibt es nicht. easybill hatte Anwendung und Website am Mittwochnachmittag abgeschaltet und ist seit der Nacht wieder online. Von Shopware, Adobe Commerce/Magento, OXID, Afterbuy, Billbee, Xentral und Pickware liegt keine öffentliche Stellungnahme vor. Sansec hat RCE gegen Magento 2.4.9 bestätigt; Shopware und Magento werden nur über das PHP-Update sicher, nicht über ein Shop-Update. WordPress.org schreibt, es sei kein WordPress-Update nötig – wer PHP unter 8.2 nicht aktualisieren kann, soll die Seite offline nehmen.

Hoster-Check: Wer gepatcht hat und wer noch wartet

Stand Donnerstag, 22. Oktober, 10:00 Uhr, nach den Statusseiten der Anbieter und der Übersicht von Severint . Alle Zeiten in MESZ.

• Hetzner (Status ): PHP 7.4 und 8.0 bis 8.5 um 19:50 Uhr gepatcht, 5.6 und 7.3 um 6:32 Uhr. Dedicated- und Cloud-Kunden patchen selbst.
• Mittwald (Status ): Komplettabschaltung ab 16:17 Uhr, Patches 7.2 bis 8.5 um 22:52 Uhr ausgerollt, um 0:28 Uhr „gelöst“. Versionen unter 5.6 bleiben offen.
• netcup (Status ): Webhosting und Managed Server ab 16:25 Uhr offline, um 23:45 Uhr alle Systeme online. Control Panel erst um 4:09 Uhr nach Plesk-Patch. Root-Server und VPS: Kunden patchen selbst.
• Timme Hosting (Status ): Alle Websites ab 15:31 Uhr deaktiviert, 8.2 bis 8.5 um 19:24 Uhr gepatcht, alle Versionen ab 5.6 um 22:20 Uhr. Kundenseitige Wartungsmodi müssen selbst entfernt werden.
• Profihost (Status ): 8.2 bis 8.5 um 20:20 Uhr gepatcht. 7.4 bis 8.1 seit 8:49 Uhr in der Testphase, 5.6 bis 7.3 werden angepasst – noch offen.
• IONOS (Status ): Sicherheitswartung seit 17:44 Uhr, Abschluss „binnen 24 Stunden“ angekündigt. Um 6:53 Uhr weiter in Arbeit, keine Versionsliste. VPS und Bare Metal: Kunden patchen selbst.
• Host Europe (Status ) und DomainFactory (Status ): Wortgleiche „Wartung des Hostings“ seit 18:46 Uhr, Shared und Web Hosting „Under Maintenance“, keine Abschlussmeldung. Im Sellerforum berichtet ein Händler, sein DomainFactory-Webspace sei am Donnerstagmorgen noch auf PHP 8.2.31 gelaufen; er hat seine Seiten in einer Nachtschicht zu Hetzner umgezogen und den Account nach 25 Jahren gekündigt.
• all-inkl: Keine Statusseite. Laut Instagram-Meldung erste Server ab 17:50 Uhr aktualisiert, Großteil bis Donnerstagmorgen, KAS und Webmail zeitweise eingeschränkt. Für Versionen außerhalb des Supports „alternative Absicherung“ in Arbeit.
• dogado, checkdomain, Alfahosting (eine Gruppe): Updates „mit höchster Priorität“ seit 16:08 Uhr, kein Abschluss gemeldet. Alfahosting hat um 7:15 Uhr eine weitere Wartung auf allen webX-Servern begonnen, CloudPit-Login gestört.
• Strato, webgo, 1blu, goneo, Raidboxes: Keine öffentliche Stellungnahme gefunden. Für Strato gibt es nur einen Leserkommentar („19:10 Uhr gepatcht“), unbestätigt.
• maxcluster (Status ): Keine PHP-Meldung auf der Statusseite, nur eine Infrastruktur-Wartung am 21. Oktober. PHP Lücke ist gepatcht.
• Uberspace, Contabo, manitu, creoline: gepatcht. Uberspace hat PHP-8.1-Nutzer zwangsweise auf 8.2 gehoben, manitu lässt Upload-Beschränkungen vorerst bestehen.

Die Lage bei den Linux-Distributionen: Debian 12 und 13 sowie Ubuntu 22.04, 24.04 und 26.04 haben Pakete. Ubuntu 20.04 und älter nur über Ubuntu Pro. Debian 11 nur über kostenpflichtiges ELTS. Wer einen eigenen Server betreibt, muss nach dem Update Apache komplett neu starten – ein graceful reicht bei mod_php nicht – und bei LiteSpeed die lsphp-Prozesse beenden.

Amazon, eBay, Otto, Kaufland: Wortfilter hat nach Kulanz gefragt

Händler, deren ERP seit Mittwoch nicht erreichbar ist, können Versandbestätigungen nicht rechtzeitig übermitteln, Kundenanfragen nicht in 24 Stunden beantworten und Bestände nicht abgleichen. Das wirkt sich auf die Kennzahlen aus, die Amazon, eBay, Otto und Kaufland für die Bewertung der Serviceleistung heranziehen – von der Rate verspäteter Lieferungen bis zur Reaktionszeit. Der Autor hat die großen Plattformen angefragt, ob sie die Bewertung der Serviceleistungen für den Ausfallzeitraum aussetzen oder Verstöße aus diesem Zeitraum neutral behandeln. Eine Antwort liegt bis Redaktionsschluss von keiner Plattform vor. Auch öffentlich haben sich Amazon, eBay, Otto und Kaufland bisher nicht zur PHP-Lücke oder zu Kulanzregelungen geäußert. Wortfilter aktualisiert diesen Beitrag, sobald Antworten eintreffen. Anzumerken ist, dass durch die Nichtreaktion der großen Plattformen Händler verunsichert werden.

Die Kette ist so stark wie ihr ältestes PHP

Der Patch war 24 Stunden nach dem Leak da. Dass trotzdem Behördenseiten, Kliniken, Shops und ERP-Systeme am zweiten Tag noch offline sind, liegt nicht am PHP-Projekt, sondern an der Kette dahinter: Distribution, Hoster, Control Panel, Docker-Image, Agentur, Händler. Jedes Glied braucht Stunden, und jedes Glied mit PHP 7.4 oder 8.0 braucht einen Patch, den niemand offiziell liefert. Die Hoster, die am Mittwoch alles abschalteten, hatten am Donnerstagmorgen die saubersten Statusseiten. Die, die schwiegen, haben jetzt Händler, die ihre Seiten in einer Nachtschicht wegziehen. Und bis die Marktplätze antworten, zahlt der Händler die Kennzahlen für einen Ausfall, den er nicht verursacht hat.