Stand: 23. Oktober 2026
Der Hoster webgo hat ausführlich auf unsere Presseanfrage zu PHP2Shell geantwortet. Das Marketing-Team von webgo schildert darin, wann die Sicherheitsupdates auf welchen Systemen eingespielt waren, warum webgo seine Server nicht vorsorglich abgeschaltet hat und wie Kunden prüfen können, ob ihre PHP-Version gepatcht ist. Wie die übrigen deutschen Hoster auf die beiden Lücken reagiert haben, steht in unserer Übersicht: Wie deutsche Webhoster auf PHP2Shell reagieren.
Kurz zur Einordnung: PHP2Shell steht für die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619. Sie sind mit CVSS 9.2 bewertet, und ein Angreifer braucht keinen Login, eine präparierte Webanfrage genügt. Das PHP-Projekt hat am 21. Oktober 2026 gegen 15:35 Uhr MESZ die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht.
Das Wichtigste in Kürze
- Laut webgo sind die Updates auf allen Shared-Hosting- und Managed-Systemen installiert, auch für ältere PHP-Versionen bis einschließlich 5.6.
- Der letzte verwaltete vServer war laut webgo am 22. Oktober um 23:24 Uhr aktualisiert.
- Eine vorsorgliche Abschaltung hat webgo geprüft, sich aber dagegen entschieden.
- Kunden mit selbst verwalteten Root-Servern müssen PHP selbst aktualisieren.
- Bestätigte Kompromittierungen sind webgo nach eigenen Angaben derzeit nicht bekannt.
Chronik: Wann webgo welche Systeme aktualisiert hat
Nach Angaben von webgo hat das Technikteam unmittelbar nach der Veröffentlichung der Sicherheitsupdates am 21. Oktober mit der Aktualisierung begonnen. Die einzelnen Schritte laut webgo (Uhrzeiten in MESZ):
| Zeitpunkt |
Stand laut webgo |
| 21. Oktober, abends |
Nahezu alle Webhosting-Server sind aktualisiert. |
| 22. Oktober, 02:06 Uhr |
Die gesamte Webhosting-Plattform, alle managed KVM NVMe vServer und alle managed Dedicated Server sind aktualisiert. |
| 22. Oktober, 10:13 Uhr |
Auch die deutliche Mehrheit der managed SSD vServer ist aktualisiert. An den übrigen SSD- und HDD-vServern wird weitergearbeitet. |
| 22. Oktober, 23:24 Uhr |
Der letzte verbliebene managed vServer ist aktualisiert. Damit sind beide Lücken auf allen von webgo verwalteten Systemen geschlossen. |
Dass sich die Arbeiten bis in den späten Abend des 22. Oktober zogen, begründet webgo mit der Hardware und der Größe einzelner Systeme: „Einzelne vServer, insbesondere HDD-Systeme, oder besonders große Server benötigten für die Aktualisierung Hardware oder Volumen bedingt, teilweise deutlich mehr Zeit.“ Außerdem habe die zeitweise Überlastung der Quellserver für die Updates für Verzögerungen gesorgt. (Stellungnahme von webgo gegenüber severint.net, 23. Oktober 2026)
Warum webgo nicht abgeschaltet hat
Mehrere Hoster haben ihre Systeme am 21. Oktober vorsorglich vom Netz genommen. webgo hat diesen Schritt nach eigener Aussage erwogen, aber nicht gemacht. Unmittelbar nach Bekanntwerden der Lücken habe man mögliche Schutzmaßnahmen geprüft, die Veröffentlichungen des PHP-Teams verfolgt und die eigenen Systeme gezielt auf ungewöhnliche Aktivitäten beobachtet.
„Eine vorsorgliche Abschaltung haben wir ausdrücklich als Handlungsoption geprüft. Auf Grundlage der jeweils vorliegenden Erkenntnisse haben wir uns für den Weiterbetrieb unter engmaschiger Beobachtung und die schnellstmögliche Installation der Sicherheitsupdates entschieden.“
Stellungnahme von webgo gegenüber severint.net, 23. Oktober 2026
Diese Bewertung habe fortlaufend gegolten. Bei einer veränderten Gefährdungslage hätte webgo nach eigenen Angaben weitere Einschränkungen bis hin zur Abschaltung betroffener Systeme vorgenommen. Nötig geworden sei das nicht.
Alte PHP-Versionen bis 5.6: gepatcht, aber mit alter Versionsnummer
Das PHP-Projekt selbst hat korrigierte Versionen nur für PHP 8.2 bis 8.5 veröffentlicht, für PHP 7.4, 8.0 und 8.1 gab es lediglich minimale Source-Backports. webgo bietet ältere Versionen über seinen PHP Extended Support an und hat laut eigener Aussage auch diese abgesichert, bis einschließlich PHP 5.6.
Dabei gibt es eine Besonderheit, die viele Kunden irritieren dürfte: Die Korrekturen wurden in die bestehenden Versionen zurückportiert. Die Versionsnummer ändert sich deshalb nicht. webgo schreibt dazu:
„Die Besonderheit bei den EOL Versionen ist jedoch, dass diese durch Backporting gepatched wurden und somit keine neue Versionsbezeichnung erhalten. Den Sicherheitsstand erkennt man in diesen Version jedoch am Build-Datum.“
Stellungnahme von webgo gegenüber severint.net, 23. Oktober 2026
So prüfen Sie es: Rufen Sie eine phpinfo()-Seite Ihrer Website auf und sehen Sie sich den Eintrag „Build Date“ an. Steht dort laut webgo der 21.10.2026 oder ein späteres Datum, enthält die PHP-Version die Korrekturen. Eine solche Testdatei sollten Sie nach der Prüfung wieder löschen, weil sie viele Details über den Server verrät. Mehr dazu erklärt webgo auch in seinem Blogbeitrag zu den PHP-Sicherheitslücken.
Wie webgo seine Kunden informiert hat
Laut webgo erfuhren Kunden zuerst im Kundenportal von den Lücken. Danach folgten ein Hinweisbanner auf der Website und ein öffentlicher Blogbeitrag, die webgo nach eigenen Angaben jeweils mit dem Fortschritt aktualisiert hat. Am 23. Oktober hat webgo zusätzlich begonnen, eine abschließende Informationsmail an alle Kundenaccounts zu verschicken. Damit will webgo auch diejenigen erreichen, die den bisherigen Verlauf nicht mitbekommen haben.
Root-Server: Kunden müssen selbst patchen
Die Updates von webgo betreffen nur die Systeme, die webgo selbst verwaltet. Wer einen selbst verwalteten root vServer oder root Dedicated Server betreibt, ist für PHP selbst verantwortlich:
„Kund:innen mit selbst verwalteten root vServern oder root Dedicated Servern müssen ihre PHP-Installationen selbst aktualisieren.“
Stellungnahme von webgo gegenüber severint.net, 23. Oktober 2026
Sofern noch nicht geschehen, sollten dort laut webgo umgehend die passenden Sicherheitsupdates für alle eingesetzten PHP-Installationen eingespielt werden. Außerdem empfiehlt webgo, diese Systeme auf verdächtige Aktivitäten und mögliche Anzeichen einer Kompromittierung zu prüfen.
Keine bekannten Kompromittierungen, aber keine Garantie
Nach aktuellem Kenntnisstand hat webgo bei seiner Überwachung keine besonderen Auffälligkeiten festgestellt, die sich den beiden PHP2Shell-Lücken zuordnen ließen. Bestätigte Kompromittierungen im Zusammenhang mit den Schwachstellen seien derzeit nicht bekannt. webgo schränkt das selbst ein:
„Diese Aussage beschreibt unseren derzeitigen Erkenntnisstand und ist keine pauschale Zusicherung, dass keinerlei Angriffsversuche stattgefunden haben.“
Stellungnahme von webgo gegenüber severint.net, 23. Oktober 2026
Einordnung
Im Vergleich der deutschen Hoster aus unserer Übersicht gehört webgo zu den Anbietern, die ohne Abschaltung durchgepatcht haben. Timme Hosting dagegen hat am 21. Oktober vorübergehend alle Websites deaktiviert und begründet das damit, dass die Angriffsfläche zu diesem Zeitpunkt nicht abschließend bewertbar gewesen sei. Auch kyberio nahm seine Shared-Hosting-Systeme vorsorglich offline. Webhosting Franken hielt nach eigenen Angaben keine Abschaltungen für nötig, weil die Updates am 21. Oktober kurz nach 16 Uhr eingespielt waren.
Bis alle verwalteten Systeme gepatcht waren, vergingen bei webgo laut eigener Chronik gut 30 Stunden; der Großteil, nämlich Webhosting, NVMe vServer und Dedicated Server, war in der Nacht zum 22. Oktober fertig. Die unveränderte Versionsnummer nach einem Backport betrifft nicht nur webgo: Auch Host Europe weist darauf hin, und Alfahosting, dogado und checkdomain nennen wie webgo das Build Date in phpinfo() als Prüfmerkmal.
Für Kunden heißt das: Im Webhosting und auf den managed Servern von webgo müssen Sie nichts tun. Wer einen eigenen Root-Server bei webgo betreibt, sollte PHP sofort aktualisieren und das System auf Spuren eines Angriffs prüfen.