PHP2Shell
Warum wegen einer PHP-Sicherheitslücke nicht alle Websites vom Netz müssen

Statt Panik, einfach bewusst entscheiden

Am 21. Oktober wurden zwei kritische Sicherheitslücken in PHP bekannt, der Programmiersprache, in der WordPress läuft. Im Netz las man Warnungen vor Massenangriffen „innerhalb von 15 Minuten“ und Empfehlungen, Websites stunden- oder tagelang vom Netz zu nehmen. Wir haben die Nacht durchgearbeitet. Von den knapp 60 Websites, die wir betreuen, gingen nur zwei vom Netz – beide auf Wunsch unserer Kund:innen.

In diesem Artikel erfahrt ihr:

• was passiert ist,
• warum wir nicht alles abgeschaltet haben,
• welche zwei Fragen ihr eurem Hosting-Partner jetzt stellen solltet
• und wer dafür gesorgt hat, dass das Internet am nächsten Morgen noch funktionierte (es waren nicht wir!).

Was am 21. Oktober passiert ist

PHP ist die Programmiersprache, in der WordPress und ein großer Teil aller Websites laufen. Wenn WordPress das Haus ist, ist PHP das Fundament. Und genau dort steckten die beiden Lücken (CVE-2026-109618 und CVE-2026-109619).

Beide Lücken haben dasselbe Grundproblem: PHP arbeitet mit Daten weiter, denen es eigentlich nicht mehr trauen dürfte. Genau das können Angreifer:innen ausnutzen, um eigene Befehle auf dem Server auszuführen. Im Detail:

• Bei der ersten Lücke geht PHP der Speicher aus, während es eine Anfrage noch liest. Es bricht ab und räumt danach auf, als wäre alles vollständig, mit halbfertigen Daten.
• Bei der zweiten nimmt ein PHP-Prozess Reste einer Anfrage mit in die nächste und vertraut ihnen, obwohl sie längst ungültig sind.

Angreifer:innen konnten beides ganz ohne Passwort auslösen, noch bevor WordPress überhaupt startete. Das PHP-Team stufte beide Lücken mit 9,2 von 10 Punkten als kritisch ein.

Die Updates erschienen am 21. Oktober um 16:00 Uhr, einen Tag früher als geplant, weil Details vorab geleakt wurden. Zeitgleich veröffentlichte php.net Übergangsmaßnahmen für alle, die noch nicht aktualisieren konnten. Das sind geänderte Einstellungen am Server, die die bekannten Angriffswege versperren. Vollständig schützen sie laut php.net nicht, sicher ist nur das Update. Am Abend kursierte bereits ein öffentlicher Proof of Concept, also ein funktionierender Beispielangriff.

Die Nervosität hatte also einen echten Grund. Schon bei der WordPress-Lücke wp2shell im Juli 2026 haben wir gesehen, wie KI-gestützte Werkzeuge helfen, aus einem Patch in wenigen Stunden einen Angriff zu bauen. Ein Patch ist das Sicherheits-Update, das eine Lücke schließt. Er verrät aber auch, wo genau sie steckt. Die Prognose von Massenangriffen 15 Minuten nach dem Release war nicht zutreffend, auch wenn es schon vor der Veröffentlichung der Updates vereinzelt erste Angriffe gab. Global meldete Cloudflare schon nach wenigen Stunden Hunderttausende Angriffsversuche. Auf unseren Servern kam bis zum nächsten Tag kein einziger Angriffsversuch auf diese Lücken an, und die Zahl der automatisch gesperrten Angreifer:innen blieb auf normalem Niveau. Zum Vergleich: Bei wp2shell zählten wir auf unseren Servern in den ersten Tagen über 4.300 Zugriffe auf die verwundbare Stelle.

Warum wir nicht alles abgeschaltet haben

Unser Plan stand vorher fest: Bis zum Einspielen der Updates sichern wir unsere Server so weit wie möglich zusätzlich ab. Ob Websites abgeschaltet werden müssen, entscheiden wir erst, wenn Updates und offizielle Übergangsmaßnahmen vorliegen. In Stein gemeißelt war unser Plan nicht. Wir haben laufend geprüft, ob neue Informationen die Lage verändern. Hätte sich das Bild geändert, hätten wir jederzeit umgeschwenkt.

Die Übergangsmaßnahmen waren schnell klar und haben die bekannten Angriffswege weitestgehend geschlossen. Als die ersten Berichte über echte Angriffe kamen, haben wir zwei weitere Schutzmaßnahmen ergänzt. Außerdem haben wir die automatische Erkennung gezielt auf diese Angriffe eingestellt. Mit jeder neuen Information wurden wir sicherer, dass die Entscheidung richtig war.

Vor allem aber ist Abschalten bei uns eine Sache von Sekunden. Die Skripte lagen bereit, um eine einzelne Website, alle Websites oder ganze Server mit einem einzigen Befehl sauber vom öffentlichen Internet zu trennen. Wer berechtigterweise Nutzer:innen vorab informieren muss und eine halbe Stunde benötigt, um eine Website und dahinterliegende Dienste abzuschalten, muss diese Entscheidung vorsorglich treffen. Wer aber wie die meisten reinen Kommunikations-Websites es in Sekunden kann, darf beobachten und im Notfall sofort handeln.

Zwei Kund:innen haben uns vorab gebeten, ihre Websites bis zum Update vom Netz zu nehmen – eine aus Vorsicht, eine auf Beschluss einer übergeordneten Ebene. Diesen Anfragen sind wir selbstverständlich sofort nachgekommen.

So lief die Nacht bei uns:

Zeitpunkt	Was passiert ist
16:00 Uhr	Updates veröffentlicht
wenige Minuten später	Erste Server aktualisiert, alle Websites einzeln geprüft
direkt danach	Übergangsmaßnahmen von php.net auf allen noch wartenden Servern, automatische Angriffserkennung ab jetzt alle 5 Minuten
am Abend	Ein weiterer Server aktualisiert
kurz nach Mitternacht	Letzte Server aktualisiert, sobald ihre Pakete verfügbar waren
direkt nach jedem Update und für alle Server nochmals am nächsten Morgen	Abgleich aller Website-Dateien mit dem Originalzustand, Schwachstellen- und Malware-Scan

Für die letzten Server haben die Übergangsmaßnahmen rund acht Stunden überbrückt. In dieser Zeit lief die automatische Angriffserkennung etwas über 100 Mal, ohne einen einzigen Befund.

Wann Abschalten trotzdem richtig ist: Manche Websites verarbeiten personenbezogene oder besonders sensible Daten, etwa Spenden, Gesundheitsdaten, Mitgliederbereiche oder Bewerbungen. Dann kann es richtig sein, sie bis zum Update vom Netz zu nehmen oder die betroffenen Funktionen zu sperren. Das gilt auch für alle, die weder schnell aktualisieren noch absichern noch überwachen können. Für die vielen Websites, die vor allem informieren, ist ein tagelanger Shutdown dagegen ein hoher Preis für wenig zusätzliche Sicherheit.

Wichtig ist dabei, wo die Daten tatsächlich liegen. Die meisten Websites speichern Spenden oder Anmeldungen nicht selbst. Sie reichen sie direkt an Fachsysteme weiter, etwa an Spendenplattformen, Newsletter- oder Buchhaltungstools. Dort liegen oft Zehntausende Datensätze, und dort wäre ein Angriff besonders folgenreich. Websites, die Daten nur weitergeben oder kurz zwischenspeichern, sind Grenzfälle. Sind sie abgesichert und eng überwacht, ist das Risiko nach unserer Einschätzung gering. Die Entscheidung trifft am Ende jede:r Betreiber:in selbst, und wer abschalten möchte, bei dem setzen wir das sofort um.

Und wenn es doch eine Website getroffen hätte?

Im schlimmsten Fall gelingt ein Angriff auf einer einzelnen Website. Sie wäre nach wenigen Minuten offline gewesen, alle anderen wären weitergelaufen. Dafür sorgen zwei Dinge:

• Jede Website wohnt auf unseren Servern wie in einer eigenen Wohnung mit eigenem Schlüssel. Technisch heißt das: Sie läuft unter einem eigenen Benutzerkonto auf dem Server und mit eigenem PHP. Wer über eine Website eindringt, kommt nicht sofort in die Wohnungen nebenan.
• Die automatische Angriffserkennung prüfte am Höhepunkt alle fünf Minuten auf typische Spuren: fremde Programme, ungewöhnliche Verbindungen nach außen, neue PHP-Dateien. Dazu kamen Sofort-Alarme, wenn ein Server ungewöhnlich stark ausgelastet war oder auffällig viele Daten verschickte. Ein weiteres System sperrte erkannte Angreifer:innen automatisch aus.

Das wäre der Zeitpunkt gewesen, eine Website auf Knopfdruck aus dem Netz zu nehmen. Danach hätten wir zuerst das Update eingespielt, damit dieselbe Lücke nicht sofort wieder offen ist. Dann hätten wir ein Backup von vor dem Angriff zurückgespielt. Daten, die seitdem dazugekommen sind, etwa aus Formularen oder Bestellungen, hätten wir gezielt nachgeholt. Außerdem hätten wir alle Passwörter und Zugangsschlüssel der Website ausgetauscht. Und wir hätten geprüft, ob personenbezogene Daten betroffen sein könnten. In dem Fall gilt die 72-Stunden-Meldepflicht nach Art. 33 DSGVO.

Die Grenzen, offen gesagt: Laute Angriffe wären in Minuten aufgefallen. Ein leiser Angriff, der nur Daten liest, hinterlässt kaum Spuren. Dafür sind die Prüfungen danach da. Und die Trennung der Websites hält nur, solange es nicht zusätzlich eine Lücke im Betriebssystem gibt. Hundertprozentige Sicherheit gibt es nicht. Ein begrenzter, beherrschbarer Schaden ist trotzdem etwas völlig anderes als „das Ende des Internets“. Dieses Bild wurde durch das LinkedIn-Dorf und sogar durch klassische Medien getrieben.

Zwei Fragen, die ihr eurem Hosting-Partner jetzt stellen solltet

Ob euer Hosting- oder Wartungspartner auf so eine Nacht vorbereitet war, findet ihr mit zwei Fragen heraus. Mit Teamgröße hat das wenig zu tun. Unser Team für die System-Administration, also die Verwaltung der Server, besteht aus zwei Personen. Mit ausgezeichneten Werkzeugen und viel Erfahrung betreuen sie rund 20 Server.

1. „Wie wart ihr vorbereitet?“

Eine gute Antwort klingt nach Routine. Man weiß, auf welchem Server welche PHP-Version läuft und woher ihre Updates kommen. Die Abläufe stehen vorher fest. Die üblichen Handgriffe liegen als fertige Skripte bereit, also als kleine Programme, die in Sekunden auf allen Servern gleichzeitig laufen. Wo es noch keine Updates gibt, werden die offiziellen Übergangsmaßnahmen umgesetzt. Solange Server angreifbar sind, werden sie eng überwacht. Vor riskanten Schritten gibt es frische Backups von der Datenbank, den Website-Dateien und vom ganzen Server.

Nervös werden solltet ihr, wenn ihr nur hört „Ein Skript versucht alle zehn Minuten das Update“ und die Worte Absicherung, Überwachung und Backups gar nicht fallen.

2. „Wie könnt ihr sicher sein, dass in dieser Zeit niemand eingedrungen ist?“

Ein Update schließt die Tür, sagt aber nichts darüber, ob vorher jemand drin war. Eine gute Antwort nennt konkrete Prüfungen. Dazu gehören die Protokolle der Server, auffälliger Datenverkehr und ungewöhnliche Auslastung. Dazu kommen ein Abgleich aller Dateien mit dem Originalzustand, Scans nach Schadsoftware und Schwachstellen und eine Prüfung der Datenbank auf Veränderungen.

Bei uns waren das rund eine Million Dateien, die direkt nach den Updates und erneut am Morgen danach geprüft wurden. Jede Datei wurde mehrfach kontrolliert: mit den offiziellen Prüfsummen, einer Art digitalem Fingerabdruck jeder Originaldatei, und mit zwei Programmen, die nach Schadsoftware suchen. Es gab keinen Befund.

Nervös werden solltet ihr bei „hundertprozentig sicher“ und wenn niemand sagen kann, welche Schritte unternommen wurden. Eine Ausnahme ist vielleicht, wenn alle Websites während der gesamten kritischen Zeit offline waren.

Und falls ihr von der Lücke erst durch diesen Artikel erfahrt, ist auch das eine Antwort.

Wer das Internet in dieser Nacht zusammengehalten hat

Viele Server laufen mit den Linux-Systemen Debian oder Ubuntu. PHP kommt dort sehr oft aus den fertigen Installationspaketen von Ondřej Surý. Hauptberuflich leitet er beim Internet Systems Consortium die Entwicklung rund um BIND. Diese Software übersetzt in großen Teilen des Internets Adressen wie allcodesarebeautiful.com in die Nummern, die Computer brauchen. Die PHP-Pakete baut er nebenbei, nach eigenen Worten „mostly in my free time“.

Wie der 21. Oktober für ihn aussah, steht in seinem öffentlichen Issue. Am späten Vormittag schrieb er, durch das vorgezogene Release bleibe weniger Zeit als geplant, und sein Rechner zum Bauen der Pakete laufe bereits unter Volllast. Am Mittag kündigte er an: Zuerst kommen die Pakete für gängige Intel- und AMD-Server, danach die für ARM-Server. Eine Zeitschätzung gab er bewusst nicht mehr ab. Am Abend meldete er, dass allein das Bauen für ARM-Server über fünf Stunden gedauert hatte. Ein Mensch hat an einem Tag PHP für sechs Linux-Distributionen neu gebaut, und unzählige Server weltweit haben darauf gewartet, unsere eingeschlossen.

Zur Fairness gehört: Ondřej Surý schrieb selbst, der Engpass seien Werkzeug und Zeit, nicht Geld. Auf GitHub Sponsors erreichen seine 219 Unterstützer:innen trotzdem nur 7 % des Monatsziels, mit dem er sich ganz auf diese Arbeit konzentrieren könnte. Ein Einzelfall ist das nicht, das zeigen xkcd 2347, der xz-Backdoor 2024 und OpenSSL, das vor Heartbleed mit weniger als 2.000 Dollar Spenden im Jahr auskommen musste.

Unsichtbar bleibt auch die Arbeit von Sysadmins, die regelmäßig nachts an Servern sitzen, damit am nächsten Morgen alles läuft. Wir kennen solche Nächte gut, und unsere Kund:innen merken davon im besten Fall nichts. Diesmal haben aber alle hingesehen. Das kann sogar ein positiver Effekt der übertriebenen Berichterstattung und Panikmache sein, wenn wir die Aufmerksamkeit jetzt auf Menschen wie Ondřej lenken.

Kritische Lücken werden häufiger kommen, weil KI beim Finden ebenso hilft wie beim Ausnutzen. Tage wie dieser erinnern daran, wie fragil das Fundament der meisten größeren Websites ist. Und daran, wie viel an Menschen hängt, die es mit Hingabe und Verantwortungsbewusstsein zusammenhalten. Wenn das nächste Mal ein einzelner Entwickler in seiner Freizeit Software für das halbe Web neu baut, wäre ein Sponsoring der bessere Beitrag als ein weiterer Panik-Post.

Quellen

• php.net – Release 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 vom 21. Oktober 2026
• Ondřej Surý: deb.sury.org – „mostly in my free time“
• Codeberg-Issue #145 – Build-Verlauf am 21. Oktober
• GitHub Sponsors: oerdnj – Stand 22. Oktober 2026
• ISC-Profil Ondřej Surý (2023)
• xkcd 2347: Dependency
• oss-security: xz-Backdoor, 29. März 2024
• IT Pro: OpenSSL und Heartbleed