Wie Upsun mit PHP2Shell umgegangen ist: Schutzmaßnahmen waren bereits 22 Stunden vor dem Patch eingerichtet

Am 21. Oktober 2026 veröffentlichte das PHP-Entwicklerteam einen Notfall-Patch für zwei kritische Sicherheitslücken. PHP ist die Programmiersprache, auf der ein großer Teil des Internets basiert, darunter WordPress, Drupal und viele Online-Shops. Forscher von Wiz nannten die Sicherheitslücken „PHP2Shell“. Ein Angreifer könnte sie nutzen, um die Kontrolle über eine Website zu übernehmen, ohne sich jemals anzumelden.

Ein Update der Website, ihres CMS oder ihrer Plugins hilft da nicht. Die einzige wirkliche Lösung ist (und war) eine neue Version von PHP selbst.

Bei Upsun Cloud hatten wir bereits etwa 22 Stunden vor der Veröffentlichung dieses Patches WAF-Regeln zum Schutz eingerichtet. Die Kunden mussten nichts unternehmen. Sobald das PHP-Team die Patches veröffentlicht hatte, haben wir die betroffenen Websites für sie gepatcht und neu gestartet – einschließlich solcher, die auf älteren PHP-Versionen liefen, die von PHP selbst nicht mehr unterstützt werden.

So ist es passiert. Alle Zeiten sind in UTC angegeben.

Die Warnung (20. Oktober)

PHP kündigte im Voraus an, dass am nächsten Tag ein kritischer Fix kommen würde. Es gab ein paar Details, aber hauptsächlich eine Warnung.

Das reichte aus, um die Kunden von Upsun Cloud zu schützen. Jeder Besuch einer Website bei Upsun läuft zuerst über unsere Edge-Ebene, eine Schutzschicht zwischen dem Internet und den Anwendungen unserer Kunden. Eine Änderung dort schützt jeden Kunden auf einmal, ohne dass sein Code berührt wird.

Unsere Entwickler legten schnell neue Regeln fest, um genau die Anfragen zu blockieren, die die Schwachstelle am ehesten auslösen würden. Um 15:50 Uhr blockierten diese Regeln bereits Angriffe in allen Regionen. Der offizielle Patch sollte erst fast einen Tag später erscheinen.

Tag der Offenlegung (21. Oktober)

Vormittag: Vorbereitungen

Um 08:40 Uhr haben wir einen Vorfall gemeldet und die Arbeit aufgeteilt. Eine Gruppe konzentrierte sich auf die Behebung. Eine andere darauf, die Kunden auf dem Laufenden zu halten. Aus früheren Vorfällen haben wir gelernt, dass dieselben Leute nicht beides gleichzeitig gut erledigen können.

Um 09:45 Uhr waren unsere Statusseite und ein Blogbeitrag online. Beide teilten den Kunden dasselbe mit: Der Schutz ist bereits eingerichtet, und ihr müsst nichts unternehmen. Unser Support-Team verwendete für jede Frage eine vereinbarte Antwort, damit alle dieselbe Botschaft erhielten.

Den ganzen Vormittag über haben die Techniker den Schutz weiter verstärkt und weitere Regeln hinzugefügt.

Mittags: Die Angreifer schlagen früh zu

Schon am späten Vormittag suchten Angreifer im Internet nach anfälligen Websites – Stunden bevor PHP irgendwelche Details veröffentlichte. Unsere Edge-Regeln haben sie abgefangen und blockiert. Um 12:50 Uhr teilten wir den Kunden auf der Statusseite mit, dass wir Angriffe beobachteten und dass sie bereits geschützt waren.

Nachmittag: Der Patch ist da

PHP veröffentlichte den Patch gegen 13:36 Uhr, etwas früher als geplant. Er umfasste aktuelle PHP-Versionen sowie ältere Versionen, die PHP nicht mehr pflegt.

Normalerweise entscheiden Kunden selbst, wann sie ihre eigenen Plattform-Updates bereitstellen. Bei einer so schwerwiegenden Sicherheitslücke wollten wir nicht, dass jemand warten muss, also haben wir die Initiative ergriffen und den Patch für unsere Kunden angewendet.

Wir sind dabei sorgfältig vorgegangen. Das Update ersetzte lediglich PHP selbst. Es hat weder den Code noch die Konfiguration der Kunden berührt. Jede neue Version wurde in einer separaten Region getestet, bevor sie eine einzelne Kunden-Website erreichte. Und wenn bei einem Projekt Änderungen auf die Live-Schaltung warteten, haben wir diese nicht veröffentlicht. Stattdessen haben wir den Verantwortlichen kontaktiert, sodass nichts in der Produktivumgebung landete, bevor er sich für die Freigabe entschieden hatte.

Die einzige geplante Ausfallzeit war eine kurze Aktualisierung, um den Patch anzuwenden. Während dieser Aktualisierung hält Upsun eingehende Seitenanfragen zurück, bis die Seite bereit ist, sodass die meisten Besucher eine langsamere Ladezeit statt Fehlermeldungen sahen.

Am späten Nachmittag waren alle Schutzregeln in jeder Region aktiv und blockierten etwa 1.700 böswillige Anfragen pro Stunde, die größtenteils von automatisierten Angriffstools stammten.

• 18:02 Uhr: Alle aktuellen PHP-Versionen wurden in allen Upsun-Cloud-Regionen gepatcht.
• 19:13 Uhr: Wir haben einen ausführlichen technischen Beitrag für Entwickler im Upsun Developer Center veröffentlicht.
• 19:36 Uhr: Die Patches für ältere Versionen wurden nach und nach ausgerollt.

Abends: die älteren Versionen

Das Patchen der aktuellen Versionen war der erwartete Teil. Die schwierigere Arbeit war alles andere.

• Ältere PHP-Versionen, die nicht mehr unterstützt werden: wurden noch am selben Abend gepatcht. Kunden, die diese nutzten, erhielten den Fix, ohne ein Upgrade durchführen zu müssen.
• Versionen, die zu alt waren, um sie zu patchen: Wir haben jeden betroffenen Kunden direkt kontaktiert, damit niemand es erst über eine Statusseite erfahren musste.
• Websites, die nicht automatisch aktualisiert werden konnten: Auch deren Betreiber haben wir direkt kontaktiert.

Um 23:35 Uhr bestätigte die Statusseite, dass alle Upsun-Cloud-Regionen aktualisiert waren.

Am nächsten Morgen (22. Oktober)

Um 04:12 Uhr waren die letzten Patches installiert und die Statusseite wechselte in den Überwachungsmodus. Im Laufe des Tages wurden noch einige kleinere Aufräumarbeiten durchgeführt.

Was den Unterschied ausgemacht hat

Eine Schutzschicht vor jeder Website. Das ist Teil von Upsuns Sicherheitskonzept und der einzige Grund, warum wir jeden Kunden schützen konnten, noch bevor ein Fix verfügbar war – ohne dass jemand etwas ändern musste.

Wir warten PHP selbst. Als PHP Korrekturen für Versionen veröffentlichte, die nicht mehr unterstützt werden, konnten wir diese noch am selben Tag einsetzen.

Wir waren dem Problem sicher einen Schritt voraus. Wir haben den Patch proaktiv angewendet, sodass keine Website ungeschützt blieb, während ein Update in der queue stand. Es wurden nur Änderungen an PHP vorgenommen, niemals am Code oder an der Konfiguration der Kunden, und es ging nichts live, was sie nicht selbst freigegeben hatten.

Klare Rollen von der ersten Stunde an. Die Entwickler konnten sich auf die Fehlerbehebung konzentrieren. Die Kunden erhielten weiterhin klare, einheitliche Antworten.

Was du tun solltest

• Nutzt du eine unterstützte PHP-Version? Nichts. Du bist bereits auf dem neuesten Stand.
• Nutzt du eine sehr alte PHP-Version? Plane ein Upgrade. Unser Schutz verringert das Risiko, ersetzt aber keine Fehlerbehebung.
• Bist du dir nicht sicher? Bitte deine Entwickler, den Beitrag im Developer Center zu lesen, oder eröffne ein Ticket über die Upsun-Konsole.
• Läuft PHP noch irgendwo anders? Stell sicher, dass es auch dort gepatcht wird.

Die vollständige Historie des Vorfalls findest du auf der Statusseite.

Technische Details, einschließlich der betroffenen Versionen und einer Anleitung zur Überprüfung deiner Umgebung, findest du unter „Kritische PHP-Sicherheitspatches: Upsun-Rollout und was du im Upsun Developer Center überprüfen solltest“.