PHP2Shell: Warum Websites im Ernstfall offline gehen, aber nicht verstummen sollten

Mittwoch, 21. Oktober 2026. Wer die Website der Charité, der Stadt Mainz oder des Bundesamts für Migration und Flüchtlinge aufrufen wollte, landete im Nichts. Fehlermeldung. Weiße Seite. Ebenso bei Fußballvereinen, Hotels oder allgemeinen Tourismusseiten. Der Grund: PHP2Shell, zwei Schwachstellen im Kern von PHP, jener Programmiersprache, auf der nach Angaben des Sicherheitsunternehmens Wiz rund 70 Prozent aller Websites laufen. Die Antwort vieler Behörden, Kliniken und Hochschulen fiel einheitlich aus: abschalten, sofort.

Das war richtig. Auch wir haben an diesem Tag sowohl Kunden- als auch unsere eigene Website geschützt, teils vom Netz genommen, teils auf Wartungsseiten umgestellt. Unsere wichtigste Beobachtung: Die Sicherheitsentscheidung war schnell getroffen. Die eigentliche Frage war, was Nutzer:innen stattdessen zu sehen bekommen.

Was hinter PHP2Shell steckt

Der Name „PHP2Shell“ spielt auf Log4Shell an, die Java-Lücke von Ende 2021. Dahinter stecken zwei Schwachstellen, CVE-2026-109618 und CVE-2026-109619, die das PHP-Projekt mit 9,2 von 10 Punkten auf der CVSS-Skala bewertet. Angreifer können damit aus der Ferne eigenen Code auf einem Webserver ausführen. Ohne Login. Ohne dass irgendwer irgendetwas anklicken muss.

Das Besondere: Die Lücke steckt nicht in einem Plugin oder Shopsystem, sondern eine Etage tiefer, im PHP-Interpreter selbst. Damit trifft sie ein ganzes Ökosystem: WordPress, TYPO3, Shopware, Behördenportale, Intranets. Laut Sansec greift der Angriff, bevor der Code der Anwendung oder eine vorgeschaltete Web Application Firewall überhaupt zum Zug kommt. Eine sauber programmierte Website schützt also nicht.

Dazu kommen Altlasten: Eine Shodan-Auswertung zählte rund 884.000 erreichbare Server mit PHP 8.1 oder älter, für die das PHP-Projekt keine Korrektur mehr liefert. Entdeckt haben die Fehler Forscher:innen von Calif und Wiz, nach BSI-Angaben unter Beteiligung von OpenAI. Schon im Juli war mit KI-Unterstützung die WordPress-Angriffskette „wp2shell“ aufgedeckt worden. Wie KI die Suche nach Schwachstellen verändert, haben wir am Beispiel von Project Glasswing beschrieben. Schnellere Entdeckung heißt kürzere Reaktionsfenster, für die Technik wie für die Kommunikation.

Abschalten war richtig, Schweigen nicht

CERT-EU und das britische NCSC rieten, Systeme ohne sofort einspielbares Update vom Netz zu trennen. Entsprechend lang wurde die Liste: Charité, die Unikliniken in Köln, Freiburg, Heidelberg und Mannheim, Mainz, Saarbrücken, das BAMF, die Bundespolizei, Tourismus-Seiten und Vereine. Dazu Behörden in der Schweiz, den Niederlanden, Finnland und Österreich.

„Sicherheitstechnisch war das konsequent. Kommunikativ war es vielerorts ein Totalausfall“, sagt Thorsten Greiten von unserem Partner NetFed. Denn ein abgeschalteter Server beantwortet keine Fragen. Und davon gab es am Mittwoch reichlich. Findet mein Termin statt? Wurde die Klinik gehackt? Sind meine Daten in Gefahr? Die Universitätsklinika Heidelberg und Mannheim mussten öffentlich klarstellen, dass kein Cyberangriff vorlag, sondern eine Vorsichtsmaßnahme. Genau diese Klarstellung hätte auf die Startseite gehört. Nur gab es die Startseite nicht mehr.

Wo die offizielle Quelle schweigt, füllen andere das Vakuum: Social Media, Gerüchte, im ungünstigsten Fall Phishing-Mails, die sich als „dringender Sicherheitshinweis“ tarnen. Eine nackte Fehlermeldung wirkt auf Laien nicht wie Vorsicht. Eher wie Kontrollverlust. Greiten bringt es auf den Punkt: „Den Stecker ziehen ist eine Sicherheitsentscheidung. Den Mund halten ist keine.“

Dass es anders geht, zeigte eine der betroffenen Unikliniken: Sie richtete für die Außenkommunikation eine gesonderte Informationsseite ein. „Improvisiert, aber im Kern genau das richtige Prinzip“, so Greiten.

Wie wir am Mittwoch reagiert haben

Für uns hieß es am Mittwoch: schnell handeln und transparent bleiben. Rund 250 Websites waren betroffen. Wir haben die Kunden direkt informiert und die Websites bereits im Laufe des Vormittags abgeschaltet, also Stunden bevor überhaupt ein Patch existierte. Wo eine Wartungsseite vorbereitet war, haben wir sie geschaltet, sodass Nutzer:innen statt einer Fehlermeldung einen Hinweis bekamen.

Ab 16 Uhr standen die offiziellen PHP-Patches zur Verfügung, und wir haben sofort begonnen, sie auf den unterstützten Systemen einzuspielen. Docker-Images und Server-Patches brauchten deutlich länger und kamen zum Teil erst gegen 20 Uhr auf den Systemen an, die Bezugsquellen waren spürbar ausgelastet. Bis etwa 22 Uhr waren die Updates eingespielt. Ganz ohne Handarbeit ging das nicht: Teilweise mussten Entwickler:innen Anpassungen vornehmen, bevor eine Website wieder online gehen konnte. Die Wartungsseiten selbst waren meist schlicht gehalten: ein kurzer Hinweis, dass die Website aus Sicherheitsgründen vorübergehend vom Netz genommen wurde. Über den Inhalt entscheiden am Ende der Kunde oder seine Agentur. „Uns war wichtig, schnell zu handeln und unsere Kunden von Anfang an transparent einzubinden“, sagt Felix Vogt von team neusta.

Das Learning aus diesem Tag: Wo eine Wartungsseite bereitlag, war die Kommunikation mit einem Handgriff gelöst. Wo nicht, blieb nur die Wahl zwischen Risiko und Funkstille.

Wartungsseite statt Darksite: Warum das meist reicht

Naheliegend wäre eine Darksite: eine vorbereitete Krisen-Website, die im Normalbetrieb unsichtbar bleibt und im Ernstfall per DNS-Umstellung live geht. Braucht die jede Organisation?

Unsere Antwort: in den meisten Fällen nicht. „Eine Darksite bedeutet vor allem mehr Aufwand, weil die Adresse im Ernstfall umgeleitet werden muss“, so Vogt. In einem Fall wie PHP2Shell geht es schlanker. Die Wartungsseite wird geschaltet, die eigentliche Seite geht offline. „Die Nutzer landen auf dem gleichen Webserver, bekommen einfach nur eine statische Webseite ausgespielt. Die eigentliche PHP-Anwendung wird nicht angesprochen. Einen zusätzlichen Hoster braucht es dafür nicht.“

Der Trick liegt also nicht in einer zweiten Infrastruktur, sondern darin, was der Webserver ausliefert. Statt die Anfragen an die PHP-Anwendung weiterzureichen, spielt er eine statische Seite aus: reines HTML, kein PHP, keine Datenbank. Die Adresse bleibt gleich, eine DNS-Umstellung ist nicht nötig. Wer die Info-Seite selbst wieder über PHP ausliefert, hat nichts gewonnen. „Eine richtig gebaute Krisenseite hat keinen PHP-Interpreter und damit keine Angriffsfläche für diese Lücke“, erklärt Greiten. „Die verwundbare Anwendung darf vom Netz. Die Kommunikation bleibt online.“

Damit löst sich der Zielkonflikt auf, vor dem viele Verantwortliche am Mittwoch standen: Sicherheit oder Erreichbarkeit. Beides geht. Auf die Seite gehört dabei nur das Wesentliche:

Was ist passiert, und ist es ein Angriff oder eine Vorsichtsmaßnahme?
Was bedeutet das für Nutzer:innen, etwa für Termine oder laufende Anträge?
Wo gibt es Hilfe, zum Beispiel per Telefon oder E-Mail?
Wann gibt es das nächste Update?

Wann eine Darksite trotzdem sinnvoll ist

Aus Sicht der Krisenkommunikation geht Thorsten Greiten einen Schritt weiter. „Eine Darksite trennt zwei Dinge, die nie hätten aneinanderhängen dürfen: die Verwundbarkeit eines Servers und die Fähigkeit, mit der Öffentlichkeit zu sprechen.“ Ob eine Wartungsseite reicht oder es eine Darksite braucht, hängt von drei Fragen ab:

Ist die eigene Infrastruktur selbst betroffen? Die Wartungsseite liegt auf demselben Webserver und hilft nur, solange dieser läuft. Fällt nicht nur die Anwendung aus, sondern das Rechenzentrum oder der Hoster, etwa nach einem Ransomware-Angriff, braucht die Kommunikation ein komplett getrenntes Zuhause.
Braucht es mehr als einen Hinweis? Zieht sich eine Krise über Tage, mit laufenden Updates, FAQ und Pressetexten, stößt eine einzelne Wartungsseite an Grenzen.
Gibt es Veröffentlichungspflichten? Die europäische Marktmissbrauchsverordnung verpflichtet börsennotierte Unternehmen, Insiderinformationen auf der eigenen Website zu veröffentlichen und fünf Jahre vorzuhalten. Eine Investor-Relations-Seite, die nicht erreichbar ist, wird schnell zum Compliance-Thema.

Wer sich für eine Darksite entscheidet, sollte sie statisch und getrennt von der Hauptseite halten, mit vorab freigegebenen Textbausteinen arbeiten und das Umschalten regelmäßig üben. „Eine Darksite, die nie getestet wurde, ist eine Hoffnung. Kein Plan“, sagt Greiten.

Was jetzt zu tun ist

Ausgestanden ist die Lage nicht: Ein Angriffswerkzeug kursiert öffentlich, Sicherheitsfirmen melden Angriffsversuche. Eine Kompromittierung von Seiten, die vor dem Update offen im Netz standen, lässt sich nicht ausschließen.

Patchen: Auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren und alle PHP-Dienste neu starten. Kein Workaround ersetzt das Update.
Inventur machen: PHP steckt auch in Verwaltungsoberflächen, internen Fachanwendungen, Containern und Appliances.
Altversionen ablösen: PHP 8.1 und älter ist schon lange nicht mehr in Pflege und sollte somit dringend überprüft und ersetzt werden.
Spuren prüfen: Auf unbekannte Dateien, neue Benutzerkonten und ungewöhnliche Prozesse achten, vor allem auf Systemen, die vor dem Patch erreichbar waren.
Wartungsseite vorbereiten: für jede Website, statisch, ohne PHP ausgeliefert, mit geklärter Zuständigkeit für das Umschalten. Die nächste Lücke dieser Kategorie kommt bestimmt.

Was das für Unternehmen und Verwaltungen bedeutet

PHP2Shell hat gezeigt, wie stark die digitale Daseinsvorsorge an einer einzigen Komponente hängt, und wie selten die Kommunikation für diesen Fall mitgedacht ist.

Unsere Empfehlung: Eine Wartungsseite gehört grundsätzlich zu jeder Website, nicht erst, wenn die nächste Lücke bekannt wird. Sie ist schnell gebaut, macht im Normalbetrieb kaum Aufwand und hilft bei Sicherheitslücken genauso wie bei Störungen oder größeren Updates. Wer sie vorbereitet und den Umschaltweg geklärt hat, kann im Ernstfall abschalten, ohne zu verstummen. Eine eigene Krisen-Website braucht es dann meist nicht. Oder, wie Thorsten Greiten es formuliert: „Wer den Stecker zieht, sollte vorher wissen, wo das Licht weiterbrennt.“

Unser Ansatz

Wir betreiben und betreuen Websites und Webanwendungen so, dass sie auch im Ernstfall kommunikationsfähig bleiben. Vom verlässlichen Patch-Management über statische Wartungsseiten als fester Bestandteil jeder Website bis zu klaren Zuständigkeiten, auch außerhalb der Bürozeiten. Im Vorfall informieren wir unsere Kunden direkt und stimmen die nächsten Schritte gemeinsam ab. Ziel ist, dass Sicherheit und Erreichbarkeit kein Widerspruch mehr sind.

Mehr erfahren

Wer prüfen möchte, wie gut die eigene Website auf den nächsten Ernstfall vorbereitet ist, findet bei team neusta und NetFed passende Ansprechpartner:innen.

Mehr zu den Leistungen von team neusta: Managed Services & IT-Betrieb | team neusta

Kontakt bei team neusta: Felix Vogt, f.vogt@neusta.de

Mehr zu den Leistungen unseres Partners: Digital Marketing, Website Relaunch & Conversion Optimierung | NetFed

Kontakt bei NetFed: Thorsten Greiten, thorsten.greiten@net-federation.de