Vor einer Woche haben wir an dieser Stelle vor PHP2Shell gewarnt, zwei kritischen Sicherheitslücken in PHP, der Technik hinter einem Großteil des Webs. Seitdem ist viel passiert: Die Lücken wurden angegriffen, ein Teil der Welt hat hektisch gepatcht, und manche Websites gingen vom Netz. Bei den Websites unserer Kunden war das nicht nötig. Keine einzige musste offline genommen werden.
Das ist kein Zufall und auch kein Grund zur Selbstzufriedenheit, sondern das Ergebnis von Vorbereitung. Aber der Reihe nach: Zuerst ein ehrlicher Rückblick, was wirklich passiert ist, danach, warum wir ruhig bleiben konnten und was du daraus mitnehmen kannst.
Was in dieser Woche passiert ist
Die Vorgeschichte. Laut TechTarget wurden die Fehler schon im Sommer von Sicherheitsforschern gefunden, unter anderem mit Hilfe von KI-Werkzeugen, und im September begann das PHP-Team an einem abgestimmten Fix zu arbeiten. Geplant war eine geordnete Veröffentlichung.
Der Leak. Am 20. Oktober sickerten Details vorzeitig durch. Das PHP-Team kündigte daraufhin das Update für den 21. Oktober an. Amazon meldete schon am 17. Oktober erste Angriffsversuche auf seine Sensoren, also vier Tage vor dem Patch. Am Morgen des 21. Oktober tauchte laut TechTarget außerdem ein Anbieter von Container-Images mit dem Fix auf, mehr als sechs Stunden vor der offiziellen Freigabe.
Der Patch. Am 21. Oktober um 14:00 UTC erschienen die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ältere Versionen bekommen offiziell keinen Fix. Einige Linux-Distributionen wie Debian, Red Hat und Ubuntu haben laut Greenbone trotzdem Pakete veröffentlicht, teils auch für ältere Zweige.
Die Angriffe. Die Zahlen schwanken je nach Quelle stark. Laut TechTarget meldete der Sicherheitsanbieter Imperva in den ersten 24 Stunden 482.342 Anfragen gegen 21.998 Websites in 103 Ländern. Wordfence blockierte bis 22. Oktober mehr als 74.000 Angriffs- oder Sondierungsversuche. Cloudflare sprach von Millionen Exploit-Versuchen. Wichtig: Das sind überwiegend Versuche, nicht erfolgreiche Einbrüche.
Der Ernstfall. Am 26. Oktober berichtete BleepingComputer, dass ein Sicherheitsforscher bei Perplexity mit Honeypots einen erfolgreichen Angriff auf einen Apache-Server mit PHP 8.4.26 beobachtet hat. Das ist ein Server, der den Patch noch nicht hatte. Auch die US-Behörde CISA hat die Lücken am selben Tag in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen (laut SOCRadar).
Die Folgen für Websites. TechTarget berichtet, dass hunderte Websites vom Netz gingen, darunter Regierungsseiten in mehreren Ländern, mit einem Höhepunkt am 21. Oktober. Wie viele davon tatsächlich gehackt wurden und wie viele aus Vorsicht abgeschaltet wurden, ist öffentlich nicht sauber aufgeschlüsselt.
Der Stand der Updates. Eine Woche später ist vieles noch offen. Ein Tracker, den TechTarget zitiert (mit unklarer Methodik), sah am 27. Oktober erst rund 21 Prozent der erkennbaren PHP-Server auf dem gepatchten Stand. Große Hoster wie GoDaddy und Bluehost haben ihre verwalteten Angebote aktualisiert, bei eigenen virtuellen Servern müssen Kunden selbst ran.
Und es ist nicht vorbei. Am 23. Oktober hat das PHP-Team eine dritte Lücke offengelegt (CVE-2026-115560), die von den Updates vom 21. Oktober nicht behoben wird. Laut Greenbone und SOCRadar ist bisher keine Ausnutzung gemeldet, der Fix soll mit dem nächsten regulären Bugfix-Release kommen, bis dahin gibt es eine Abschwächung per Konfiguration. Wir behalten das im Blick.
Dazu ein Realismus-Check, damit das Bild fair bleibt: Der öffentliche Exploit ist laut Martin Cid auf bestimmte PHP-Builds zugeschnitten und kein Klick-und-fertig-Werkzeug. Ein Bitcoin-Wettbewerb auf einem absichtlich ungepatchten Server wurde nach rund 19 Stunden geknackt. Nicht jede ungepatchte Website ist also automatisch gehackt, aber das Risiko ist real und belegt.
Warum bei uns keine Website vom Netz musste
Bei unseren Kunden waren alle Websites abgesichert. Es musste keine Seite abgeschaltet werden, es gab keinen Notbetrieb und keine hektischen Nachtschichten. Das liegt an zwei Dingen.
1. Wir waren vorbereitet. Wir betreuen die Websites unserer Kunden laufend: aktuelle Software, regelmäßige Sicherheitsupdates und ein Blick auf neue Sicherheitswarnungen gehören bei uns zum Standard. Wer so arbeitet, muss bei einer Meldung wie dieser nicht bei null anfangen. Man weiß, welche Websites auf welcher Technik laufen und wer für das Patchen zuständig ist. Genau das hat bei der Lage der letzten Woche den Unterschied gemacht: Wer erst suchen muss, welche Version wo läuft, verliert die wertvollsten Stunden.
2. Nicht alle unsere Websites nutzen PHP. Das ist die zweite, ehrliche Antwort. PHP ist eine alte, bewährte Technik, aber eben auch eine, die jeden Server mit ihrem Alter und ihrer Verbreitung zur Zielscheibe macht. Viele unserer neueren Websites setzen wir deshalb mit moderner Technik um, bei der auf dem Server gar kein PHP läuft. Wo es keine PHP-Laufzeit gibt, kann auch eine PHP-Lücke nicht ausgenutzt werden.
Damit keine Missverständnisse entstehen: Das heißt nicht, dass eine Website ohne PHP unverwundbar wäre. Auch andere Technik hat Angriffsflächen, und auch dort muss man aktuell bleiben. Aber PHP2Shell hat uns gezeigt, dass weniger Altlasten im Stack konkret weniger Stress bedeuten.
Was du aus der Woche mitnehmen kannst
- Das Update gehört auf den Server, nicht in die Website. Ein WordPress- oder Plugin-Update ändert nichts. Entscheidend ist die PHP-Version, die tatsächlich Anfragen ausliefert.
- Kenne deinen Stand. Weißt du, welche PHP-Version deine Website nutzt und wer sie aktualisiert? Wenn die Antwort "keine Ahnung" lautet, ist das der eigentliche Risikofaktor.
- Alte Versionen sind ein Dauerrisiko. Wer PHP 8.1 oder älter nutzt, bekommt keinen offiziellen Fix. Wir haben das auch in unserem Beitrag über die Kärntner Webdesign-Branche beschrieben.
- Die Updates enden nicht. PHP 8.2 bekommt laut Greenbone nur noch bis 31. Dezember 2026 Sicherheitsupdates, bei PHP 8.4 endet zum selben Datum die aktive Betreuung. Plane den nächsten Wechsel jetzt, nicht im Dezember.
- Ruhe ist Vorbereitung. Der Unterschied zwischen "Wir mussten die Seite vom Netz nehmen" und "Bei uns lief alles weiter" liegt selten im Glück, sondern in Betreuung, Inventar und einem klaren Zuständigen.
Eine Detailanleitung, wie du deine PHP-Version findest und worauf du beim Hoster achten solltest, steht in unserem ersten Beitrag: PHP-Alarm: Diese Lücke kann deine Website kapern.
Wenn du jetzt unsicher bist
Du weißt nicht, ob deine Website betroffen ist, oder ob sich überhaupt jemand darum kümmert? Dann lass uns das klären. Wir sehen nach, welche Technik und welche PHP-Version läuft, ob das Update angekommen ist und was zu tun ist, egal ob wir deine Website gebaut haben oder nicht. Wenn deine Seite in die Jahre gekommen ist, besprechen wir auch gern, ob ein Neustart mit moderner Technik günstiger ist als das ewige Flicken.
Schreib uns an studio@herr-paul.at oder ruf an unter +43 650 9500530. Wir sitzen in Villach und sind für Unternehmen in ganz Kärnten und Österreich da.
Stand: 28. Oktober 2026. Die Lage entwickelt sich weiter, wir aktualisieren den Beitrag bei Neuigkeiten.
Quellen
- TechTarget: PHP2Shell explained, Timeline of the global vulnerability crisis (27. Oktober 2026)
- BleepingComputer: PHP2Shell security flaws now successfully exploited in the wild (26. Oktober 2026)
- Greenbone: PHP2Shell Remote Code Execution (zuletzt aktualisiert 27. Oktober 2026)
- SOCRadar: PHP2Shell, betroffene Versionen und Maßnahmen (zuletzt aktualisiert 27. Oktober 2026)
- Martin Cid: PHP2Shell Bitcoin-Challenge (26. Oktober 2026)