Ein Mittwoch, an dem halb Europa den Stecker zog

Gestern habe ich etwas getan, das ich meinen Mandanten sonst nur in Notfallplänen beschreibe: Ich habe meine eigenen Webseiten vom Netz genommen. Mit dem leicht mulmigen Gefühl, wie wenn man den Haustürschlüssel absichtlich in den Briefkasten wirft. Wie sich herausstellte, war ich damit in bester Gesellschaft: Ministerien, Polizeibehörden, Universitäten und Kliniken haben am Mittwoch genau dasselbe getan.

Jetzt ist die Frage: Wie geht es weiter?

Was bisher geschah

Zur Erinnerung: In der Programmiersprache PHP wurden zwei schwerwiegende Sicherheitslücken bekannt (CVE-2026-109618 und CVE-2026-109619, inzwischen unter dem Namen „php2shell“ bekannt). Über sie können Angreifer im ungünstigsten Fall aus der Ferne eigenen Programmcode auf Webservern ausführen. PHP steckt in einem Großteil aller Webseiten, unter anderem in WordPress, TYPO3, Joomla, Drupal, Shopware, Magento und Nextcloud.

Weil Details vorab durchgesickert waren, zog das PHP-Team die Veröffentlichung der Updates auf Mittwoch, 21. Oktober, 16 Uhr deutscher Zeit vor. Das BSI und die US-Behörde CISA empfahlen: Wer nicht sofort aktualisieren kann, nimmt seine Systeme vom Netz.

Ein Novum: Abschalten als Schutzmaßnahme

Diese Empfehlung wurde in einem bisher nicht gekannten Ausmaß umgesetzt. Nach Reuters gingen unter anderem in Dänemark, Finnland, Frankreich und den Niederlanden Regierungsangebote in den Wartungsmodus. In Deutschland waren laut Medienberichten unter anderem die Charité, Teile von berlin.de, Dienste der FU Berlin, die Online-Wache der Berliner Polizei sowie Behördenseiten in Bayern und Niedersachsen betroffen.

Das ist eine bemerkenswerte Entwicklung: Noch vor wenigen Jahren hätten viele Organisationen eher das Risiko in Kauf genommen als einen Tag Unerreichbarkeit. Dass so viele Verantwortliche die Empfehlung ernst genommen haben, zeigt, dass IT-Sicherheit auf Leitungsebene angekommen ist.

Die Lage heute: Patches verfügbar, Angreifer aktiv

Die Updates sind da. Das PHP-Projekt hat die abgesicherten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Die großen Linux-Distributionen (Debian, Ubuntu, Red Hat, Fedora, SUSE und weitere) haben im Laufe des Mittwochabends und Donnerstags nachgezogen, teils mit spürbarer Verzögerung, weil der vorgezogene Termin auch die Paketbetreuer überrascht hat.

Die Angriffe laufen. Cloudflare meldet Millionen von Angriffsversuchen, die schon Stunden vor der offiziellen Veröffentlichung einsetzten. Amazon will in seinen Fallen-Systemen (Honeypots) sogar schon vier Tage vorher verdächtige Zugriffe beobachtet haben und spricht inzwischen von einer breiten Ausnutzung. Bestätigte erfolgreiche Einbrüche sind bislang nicht öffentlich bekannt. Das kann sich aber schnell ändern, und manche Einbrüche fallen erst Wochen später auf.

Erste Seiten sind wieder online. Gut aufgestellte Hoster haben schnell reagiert. Beim Hoster Mittwald etwa sind Projekte schon wieder erreichbar, nachdem er sie am Mittwoch vorsorglich selbst vom Netz genommen und dann aktualisiert hatte.

Die Sicherheitsexperten sind sich einig: Ein PHP-System ohne Update gehört derzeit nicht ans Netz.

Was jetzt zu tun ist: die Checkliste

1. Patch-Stand verlässlich prüfen

  • Bei WordPress zeigt Werkzeuge → Website-Zustand → Bericht → Server die genaue PHP-Version. Sicher sind 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer.
  • Achtung: Hoster und Linux-Distributionen spielen Korrekturen teilweise ein, ohne die Versionsnummer zu ändern. Zeigt Ihre Seite eine ältere Nummer, fragen Sie konkret nach und lassen Sie sich die Absicherung schriftlich bestätigen.
  • Wer eigene Server betreibt: Nach dem Update müssen die PHP-Prozesse (z. B. PHP-FPM, Apache) neu gestartet werden. Ein installiertes Paket allein schützt nicht.

2. Alte PHP-Versionen ernst nehmen

Für PHP 8.1 und älter gibt es keine regulären Updates mehr. Hier gibt es nur Notlösungen (Rückportierungen einzelner Anbieter, kostenpflichtiger Extended Support des Hosters) oder den Umstieg auf eine aktuelle Version. Jetzt ist der Zeitpunkt, diese Altlast zu beseitigen.

3. Versteckte PHP-Systeme aufspüren

PHP läuft oft dort, wo es niemand vermutet:

  • interne Anwendungen wie Intranet, Ticketsystem, Nextcloud oder Zeiterfassung,
  • Firewalls und Router (etwa pfSense oder OPNsense),
  • NAS-Systeme mit Web-Oberfläche,
  • Raspberry Pi und andere Bastelserver, auf denen PHP als Abhängigkeit mitinstalliert wurde.

Besonders wichtig sind Systeme, die aus dem Internet erreichbar sind, auch über Fernzugriffsdienste wie QuickConnect oder Portfreigaben.

4. Nicht nur patchen, sondern nachsehen

Da Angriffe offenbar schon vor der Veröffentlichung liefen, schließt ein Update die Tür nur für die Zukunft. Wer schon drin ist, bleibt drin. Lassen Sie daher bei öffentlich erreichbaren Systemen für den Zeitraum ab etwa 17. Oktober prüfen:

  • neue oder unbekannte Administrator-Konten (z. B. in WordPress),
  • neue oder veränderte Dateien, vor allem PHP-Dateien in Upload-Ordnern,
  • unbekannte Cronjobs, SSH-Schlüssel oder Plugins,
  • auffällige Fehler in den Server-Logs und ungewöhnliche ausgehende Verbindungen.

Bei Verdacht: nichts löschen, Logs sichern, Zugangsdaten ändern und das System aus einer sauberen Sicherung von vor dem Angriffszeitraum wiederherstellen.

5. Erst dann wieder online gehen

Reihenfolge: PHP-Update bestätigt → Prüfung ohne Befund → Seite freischalten → anschließend sofort WordPress, Plugins und Themes aktualisieren.

Die datenschutzrechtliche Seite

Sicherheit nach Stand der Technik (Art. 32 DSGVO): Eine öffentlich angekündigte, kritische Lücke wissentlich offen zu lassen, wäre im Ernstfall kaum zu rechtfertigen. Das vorsorgliche Abschalten war eine angemessene technische Maßnahme.

Abschalten ist keine Datenpanne: Wer seine Seite bewusst vom Netz nimmt, löst damit keine Meldepflicht nach Art. 33 DSGVO aus. Eine Verletzung des Schutzes personenbezogener Daten setzt einen unbeabsichtigten oder unrechtmäßigen Vorgang voraus. Anders ist es, wenn die Prüfung nach Punkt 4 Hinweise auf einen tatsächlichen Zugriff ergibt: Dann läuft ab Kenntnis die 72-Stunden-Frist zur Meldung an die Aufsichtsbehörde, und der Vorfall muss bewertet werden. Einrichtungen, die unter das NIS2-Umsetzungsgesetz fallen, sollten zusätzlich ihre Meldepflichten gegenüber dem BSI im Blick behalten.

Dokumentation (Art. 5 Abs. 2 DSGVO): Halten Sie fest, wann Sie von der Warnung erfahren haben, welche Systeme betroffen waren, was Sie wann veranlasst haben und wann die Updates bestätigt wurden. Das ist Ihr Nachweis, falls später Fragen kommen.

Auftragsverarbeiter auf dem Prüfstand (Art. 28 DSGVO): Diese Woche war ein Praxistest für Hoster, Agenturen und IT-Dienstleister. Einige haben proaktiv informiert und gehandelt. Andere ließen ihre Kunden mit Standardantworten oder Rückmeldefristen von mehreren Tagen allein. Nehmen Sie diese Erfahrung mit in Ihre nächste Überprüfung: Wie schnell wurden Sie informiert? Gab es einen erreichbaren Notfallkontakt? Regelt Ihr Auftragsverarbeitungsvertrag die Information bei Sicherheitslücken mit konkreten Fristen?

Ausblick: Das war vermutlich nicht das letzte Mal

KI-gestützte Werkzeuge finden derzeit in hohem Tempo gravierende Sicherheitslücken, und sie helfen Angreifern, aus veröffentlichten Updates in kürzester Zeit Angriffswerkzeuge zu bauen. Die Zeit zwischen Bekanntwerden und Ausnutzung schrumpft von Wochen auf Stunden. Das vorsorgliche Abschalten könnte deshalb vom Ausnahmefall zur wiederkehrenden Schutzmaßnahme werden.

Sinnvoll ist es daher, sich jetzt in Ruhe vorzubereiten, statt beim nächsten Mal wieder unter Zeitdruck zu improvisieren:

  • Inventar: Welche Systeme sind aus dem Internet erreichbar, mit welcher Technik, bei welchem Dienstleister?
  • Zuständigkeiten: Wer darf entscheiden, eine Seite abzuschalten, auch abends und am Wochenende?
  • Vorbereitete Wartungsseite: Eine statische Seite und eine Anleitung zum Umschalten, die ohne PHP auskommt.
  • Notfallkontakte: Direkte Ansprechpartner bei Hoster und Agentur, nicht nur die allgemeine Hotline.
  • Kommunikationsvorlagen: Kurze Texte für Kunden, Mitarbeitende und gegebenenfalls Aufsichtsbehörden.

Eine Seite, die einen Tag offline ist, ist ärgerlich. Ein kompromittierter Server mit Datenabfluss beschäftigt Sie dagegen wochenlang.

Bei Fragen zur Einordnung, zur Meldepflicht oder zur Prüfung Ihrer Auftragsverarbeiter sprechen Sie mich gern an.

Quellen und weiterführende Informationen

 

Rechtsanwalt Robert Harzewski

Verwandte Beiträge