Kliniken, Städte und Behörden nehmen ihre Websites vom Netz. Was das für Ihre Seite heißt, und wie Sie sich in einer Stunde selbst helfen

Stand: 21. Oktober 2026, 20:10 Uhr. Ich aktualisiere diese Seite, sobald sich etwas Wichtiges ändert. Was ich noch nicht geprüft habe, steht als „noch offen“ dabei.

Was diese Seite ist, und was nicht: Information aus öffentlichen, geprüften Quellen und meiner Erfahrung, nach bestem Wissen am Tag der Veröffentlichung. Sie ist keine Beratung für Ihren Einzelfall und ersetzt keine. Was Sie an Ihrer Website, Ihrem Server oder Ihren Geräten ändern, entscheiden Sie bitte zusammen mit dem Fachmann, der Ihre Technik kennt (Hoster, Agentur, Administrator), nach der dann aktuellen Lage. Die Lage ändert sich stündlich; was heute Abend richtig ist, kann morgen überholt sein.

Was passiert ist, einfach erklärt

Seit heute Nachmittag nehmen Kliniken, Städte und Behörden ihre Websites vom Netz: in der Region Stuttgart waren am frühen Abend zeitweise acht von dreizehn großen Krankenhäusern nicht erreichbar, später noch fünf, dazu Behörden in den Niederlanden, Dänemark und Finnland, die Stadt Mainz, Wikipedia-Dienste. Nicht, weil sie gehackt wurden, sondern vorsorglich. Der Grund steckt in einem Bauteil, das fast jede Website benutzt und das kaum jemand kennt: PHP.

Was PHP ist, in zwei Sätzen: Eine Website ist nicht einfach eine Datei, die im Internet liegt. Wenn jemand Ihre Seite aufruft, baut ein Programm auf dem Server sie in diesem Moment zusammen, aus Ihren Texten, Bildern, dem Kontaktformular, dem Shop. Dieses Programm ist bei rund sieben von zehn Websites PHP. Es ist der Motor hinter der Seite: Sie sehen ihn nie, aber ohne ihn läuft nichts. WordPress, TYPO3, Joomla, Shopware, Nextcloud, fast jeder Baukasten einer Agentur, die kleine Vereinsseite von 2015, alles PHP.

In diesem Motor wurden am 21. Oktober 2026 zwei schwere Fehler öffentlich. Sie heißen zusammen „PHP2Shell“ (Kennungen CVE-2026-109618 und CVE-2026-109619) und sind mit 9,2 von 10 Punkten als kritisch eingestuft. Das Bild dazu: Jemand kann durch den Briefschlitz Ihrer Website hineingreifen und den Türöffner von innen drücken. Er braucht kein Passwort, kein Benutzerkonto, nur die Adresse Ihrer Seite. Drinnen kann er dann tun, was Ihre Website darf, und obendrein lesen, was gerade im Speicher liegt, etwa Passwörter.

Das Besondere: Betroffen sind laut den Entdeckern alle PHP-Versionen seit PHP 5, also auch sehr alte Seiten. Deshalb trifft es nicht nur Kliniken, sondern genauso die Firmenseite mit fünf Unterseiten und die Vereinsseite mit dem Terminkalender. Fertige Updates gibt es nur für PHP 8.2 bis 8.5; für 7.4, 8.0 und 8.1 stellt das PHP-Team Quelltext-Korrekturen bereit, die Hoster und Linux-Anbieter erst in Pakete gießen müssen (Ubuntu hat das für 8.1 schon getan). Das BSI stuft die Lage als „sehr hoch“ ein; Behörden in den Niederlanden, Dänemark und Finnland, Wikimedia und deutsche Städte haben Dienste vorsorglich abgeschaltet.

Wie leicht ist ein Einbruch, und was kann dann passieren?

Ich sage es so, wie ich es einem Kunden am Telefon sagen würde:

• Es geht ohne Zugangsdaten. Der Angreifer braucht nur die Adresse Ihrer Website und schickt präparierte Anfragen, etwa über ein Upload-Formular. Er muss nichts erraten.
• Es klappt nicht beim ersten Versuch, aber beim tausendsten. Die Entdecker beschreiben, dass es mehrere tausend Anfragen braucht. Für einen Menschen ist das mühsam, für ein automatisches Programm eine Sache von Minuten. Genau solche Programme laufen jetzt über das ganze Internet.
• Was dann möglich ist: Der Angreifer kann auf dem Server tun, was Ihre Website darf: Dateien lesen und ändern, eine Hintertür ablegen, Schadcode in Ihre Seiten einbauen, Kunden auf Betrugsseiten umleiten, Ihre Datenbank mit Kundendaten kopieren, Spam versenden. Eine der beiden Lücken verrät zusätzlich Inhalte aus dem Arbeitsspeicher, laut den Entdeckern bei Wiz Passwörter, Sitzungs-Token, API-Schlüssel und Zertifikate. Administrator-Rechte auf dem ganzen Server bekommt er damit nicht automatisch; dafür bräuchte er eine zweite Lücke.
• Am schlimmsten trifft es Apache mit „mod_php“: Dort greift der Angriff, bevor überhaupt Ihre Website läuft, also auch bei einer leeren Testseite. Bei der moderneren Betriebsart PHP-FPM ist ein vollständiger Angriff bisher nicht vorgeführt, aber vom PHP-Team als möglich eingestuft. Welche Betriebsart Ihr Hoster nutzt, erfahren Sie nur von ihm.
• Gibt es schon Angriffe und fertige Angriffswerkzeuge? Cloudflare sieht seit der Nacht zum 21. Oktober Angriffsverkehr auf seine Kunden; die US-Behörde CISA, das BSI und mehrere Sicherheitsfirmen hatten bis zum Nachmittag keinen bestätigten erfolgreichen Angriff. Seit dem Leak kursieren Angriffsprogramme im Netz; das SANS-Frühwarnzentrum nannte sie mittags „unzuverlässig und unvollständig“, am Nachmittag hat das RUS-CERT der Universität Stuttgart einen davon auf einem Testsystem erfolgreich nachvollzogen, und die Sicherheitsfirma watchTowr sieht Angriffe auf ihren Ködersystemen. Ein öffentlich bestätigtes echtes Opfer gibt es Stand 18:40 Uhr noch nicht. Das BSI rechnet mit Massenangriffen „innerhalb weniger Stunden“.

Deshalb mein Rat: Heute das Update, nicht am Wochenende. Meine Einschätzung des Zeitfensters: Heute und morgen ist das Risiko für die einzelne Seite noch klein, weil die Angreifer ihre Werkzeuge erst verfeinern. Ab dem Wochenende steigt es deutlich, ab der zweiten Woche rechne ich mit Masseninfektionen bei ungepatchten Seiten. Wer bis Freitag, 23. Oktober, gepatcht hat, ist mit hoher Wahrscheinlichkeit durch. Wer Personendaten im Web hat (Praxis, Kanzlei, Verein, Shop), sollte nicht so lange warten.

Bin ich betroffen? Ihr Fall auf einen Blick

Suchen Sie in der linken Spalte, was auf Sie zutrifft. Rechts steht, was Sie tun. Die Ampel ist meine Einschätzung der Dringlichkeit, Stand heute Abend.

Schritt für Schritt: PHP-Version beim Hoster umstellen

1. Sicherung anstoßen. Im Kundenbereich „Backup“ oder „Sicherung“ suchen, einmal „jetzt sichern“ klicken. Bei WordPress zusätzlich ein Backup-Plugin starten, falls vorhanden.
2. PHP-Version finden. Je nach Hoster heißt der Punkt „PHP-Version“, „PHP-Einstellungen“ oder „Webspace-Einstellungen“. Bei IONOS: Hosting → PHP-Version; bei Strato: Datenbanken und Webspace → PHP-Version; bei All-Inkl: KAS → Domain → PHP-Version. Bei Plesk: Websites & Domains → PHP-Einstellungen.
3. Die genaue Nummer lesen. Entscheidend ist die dritte Zahl: 8.3.36 ist sicher, 8.3.35 nicht. Zeigt das Panel nur „8.3“, ohne dritte Zahl, hilft bei WordPress der Blick unter Werkzeuge → Website-Zustand → Bericht → Server, bei anderen Systemen eine Rückfrage beim Hoster.
4. Umstellen und speichern. Wenn Ihre Seite noch auf 7.x oder 8.0/8.1 läuft, ist jetzt der Moment für 8.3. Die meisten aktuellen WordPress- und TYPO3-Installationen laufen damit ohne Änderung; alte Themes und Plugins können aussteigen. Dann hilft die Sicherung aus Schritt 1. Ob Ihr Hoster für die alten Zweige eine nachgebesserte Fassung anbietet, steht in seiner Versionsliste; verlassen Sie sich nicht darauf.
5. Durchklicken. Startseite, eine Unterseite, Kontaktformular abschicken, bei Shops ein Testprodukt in den Warenkorb. Weiße Seite oder Fehlermeldung? Zurück auf die vorherige Version, Sicherung einspielen, Agentur oder mich anrufen.

Wenn das Update noch nicht da ist: Übergangsmaßnahmen

Die PHP-Entwickler nennen Einstellungen, die den Angriff deutlich erschweren, aber nicht ersetzen. Sie gelten nur bis zum Update.

• Für Hosting-Kunden: Sie können diese Einstellungen nicht selbst setzen. Das PHP-Projekt sagt ausdrücklich, dass Werte in .user.ini, .htaccess oder im Code (ini_set) hier nicht greifen; bei Apache mit mod_php sind php_value-Zeilen in der .htaccess sogar Teil des Angriffswegs. Nur der Hoster kann sie serverseitig setzen (php_admin_value). Fragen Sie deshalb nach, ob er die Funktion „Upload-Fortschritt“ (session.upload_progress) abgeschaltet hat und welche Übergangsregeln laufen. Viele große Hoster nutzen dafür die Schutzregeln von Imunify360 oder eigene Filter.
• Für Server-Betreiber: in der php.ini bzw. im FPM-Pool session.upload_progress.enabled = 0, post_max_size = 8M (32M, wenn Uploads gebraucht werden), max_input_nesting_level = 8, expose_php = 0, bei PHP 8.5 fatal_error_backtraces = 0, bei PHP-FPM ein niedriges pm.max_requests. Die ebenfalls genannte Einstellung memory_limit = -1 hebt die Speichergrenze auf und kann den Server lahmlegen; nur mit Überwachung und nur kurz. Keine Speicherbegrenzung per ulimit (RLIMIT), die löst genau den Fehler aus. Nach jeder Änderung und nach dem Update alle PHP-Prozesse wirklich neu starten: ein apachectl graceful lässt das alte mod_php geladen. Die laufende Version danach über einen Seitenaufruf prüfen (phpinfo), nicht auf der Kommandozeile.
• Schutzschirm davor: Wer Cloudflare nutzt, auch im kostenlosen Tarif, bekommt Regeln, die bekannte Angriffsmuster blocken. Das ist ein Zaun, kein Fundament.
• Notbremse: Wenn nichts davon möglich ist und die Seite Kundendaten hält, lieber für einen Tag vom Netz, als ein Wochenende lang offen zu stehen. Aber richtig: Der „Wartungsmodus“ von WordPress oder Shopware hilft nicht, PHP verarbeitet weiter jede Anfrage. Es muss PHP selbst aus sein und eine statische Seite ausgeliefert werden; beim Hoster heißt das meist „PHP deaktivieren“ oder ein Ticket. Server-Betreiber können stattdessen Datei-Uploads (multipart) am Webserver sperren oder nur Lesezugriffe (GET/HEAD) zulassen.
• Der Mittelweg statt Abschalten, die „Web-Visitenkarte“: Ihre Website als reine HTML-Kopie ausliefern, also Startseite, Leistungen, Öffnungszeiten, Kontakt als feste Seiten ohne PHP. Ohne PHP gibt es nichts anzugreifen, Sie bleiben für Kunden und Google sichtbar, nur Formulare und Login sind so lange aus. Danach in Ruhe patchen, prüfen, zurückschalten. Wer Ihre Seite betreut, kann so eine Kopie in ein bis zwei Stunden ziehen; wie Sie es selbst mit KI-Hilfe machen, steht unter Selbsthilfe.

Woran erkenne ich, dass schon jemand drin war?

Die Entdecker nennen Zeichen, die bis zum Update beobachtet werden sollten. Vieles davon sehen Sie nur in den Protokollen des Servers; Ihr Hoster oder Ihre Agentur kann nachsehen.

• Plötzlich viele Fehlermeldungen „500“ oder Meldungen zum Speicherlimit, besonders nach Formular-Uploads.
• Ungewöhnlich große oder beschädigte Sitzungs-Cookies (PHPSESSID).
• PHP-Prozesse, die sich ständig neu starten.
• Für Sie selbst sichtbar: neue, unbekannte Dateien im Webspace, fremde Admin-Benutzer, ein geänderter Seitentitel, Weiterleitungen auf fremde Seiten, Warnungen von Google („Diese Website wurde möglicherweise gehackt“), Beschwerden über Spam von Ihrer Adresse.

Wenn Sie eines dieser Zeichen sehen:

1. Nicht aufräumen, erst sichern. Ein vollständiges Backup des jetzigen Zustands, inklusive Protokolle, bevor jemand etwas löscht. Das ist Ihr Beweismaterial.
2. Seite vom Netz (Wartungsseite), damit Besucher nicht gefährdet werden.
3. Passwörter ändern, von einem anderen Gerät aus: Hosting-Zugang, FTP, Datenbank, Admin-Logins, danach alle API-Schlüssel und Zertifikate erneuern, weil die Lücke genau diese Dinge verraten kann.
4. Hoster informieren, die wissen oft mehr und können Protokolle sichern.
5. Meldepflicht prüfen: Waren Kundendaten erreichbar (Shop, Praxis, Kanzlei, Verein mit Mitgliederdaten), kann eine Meldung an die Datenschutzbehörde innerhalb von 72 Stunden nötig sein. Das klären Sie mit Ihrem Datenschutzbeauftragten oder Anwalt; ich liefere die technischen Fakten dazu.
6. Erst dann neu aufsetzen, aus einer sauberen Sicherung von vor dem Einbruch, mit frischem PHP.

Wie ich bei so einem Fall vorgehe, erst Kopie, dann Spuren lesen, dann aufräumen, steht auf der Seite Nach einem Betrugsanruf: erst sichern, dann aufräumen. Für einen Server gilt dasselbe Prinzip.

Selbsthilfe: Website statisch machen, sichern, patchen, mit KI-Hilfe

Wenn Ihr Hoster noch nicht so weit ist, ist eine statische Kopie Ihrer Website die beste Übergangslösung: reine HTML-Seiten ohne PHP. Wo kein PHP läuft, gibt es für diese Lücke nichts anzugreifen; Kunden und Google sehen die Seite weiter, nur Formulare, Login und Shop sind so lange aus. Die Anleitungen dazu stehen unten zum Aufklappen: erst das Statisch-Machen, davor die Sicherung, dann der Patch für eigene Server, zuletzt, was eine statische Seite auf Dauer bringt.

Bevor Sie anfangen, zwei Regeln: Erstens, Sicherung zuerst, immer, von Dateien und Datenbank. Zweitens, lassen Sie sich von der Person begleiten, die Ihre Seite gebaut hat oder betreut, oder von Ihrem Administrator. Ohne diese Begleitung handeln Sie auf eigene Gefahr; der KI-Helfer ist ein Werkzeug, keine Vertretung für jemanden, der Ihre Technik kennt.

Du bist mein IT-Assistent, ich bin kein Techniker. Erkläre alles ohne Fachjargon, frag mich eine Sache nach der anderen, und tu nichts (löschen, hochladen, umstellen), bevor ich es ausdrücklich freigebe.

Schritt 1, Grundlage holen: Lies zuerst meine Informationsseite https://www.riedelit.de/php2shell-sicherheitsluecke-was-tun/ komplett, besonders die Abschnitte „Übergangsmaßnahmen“, „Selbsthilfe“ und „So schalten Sie die Kopie scharf“. Das ist der aktuelle Stand, den du als Grundlage nimmst.

Schritt 2, meine Angaben abfragen, eine Frage nach der anderen:
- Adresse meiner Website.
- Womit sie gebaut ist (WordPress, TYPO3, Joomla, Shop-System, Baukasten, weiß ich nicht).
- Bei welchem Hoster sie liegt und ob ich Zugang zum Hosting-Panel habe.
- Wo die Domain verwaltet wird (beim selben Hoster oder woanders) und ob ich die DNS-Einstellungen ändern kann.
- Ob der Webspace mehrere Ordner erlaubt und ob ich die Domain im Panel auf einen anderen Ordner zeigen lassen kann.
- Wer die Seite gebaut hat oder betreut, und ob ich diese Person gerade erreichen kann.
- Was die Seite können muss: Kontaktformular, Login, Shop, Terminbuchung, Suche, Newsletter, mehrere Sprachen.
- Ob es eine aktuelle Sicherung gibt, und ob mein Hoster im Panel eine Sicherung anbietet.
- Welche PHP-Version das Panel anzeigt und ob dort schon 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 wählbar ist.

Schritt 3, bewerten und Varianten vorschlagen: Fasse zusammen, was du verstanden hast, und schlage mir dann mit Begründung vor, was in meinem Fall passt:
A) Nur die PHP-Version im Hosting-Panel umstellen, wenn der Hoster die gepatchte Version schon anbietet. Dann ist die statische Kopie nicht nötig.
B) Statische Kopie als Übergang, mit dem passenden Weg zum Scharfschalten: (a) Kopie in einen anderen Ordner auf demselben Webspace und die Domain im Panel dorthin zeigen lassen; (b) wenn das lokal nicht geht: Kopie auf einen anderen Webserver oder Baukasten und die Domain per DNS dorthin umleiten; (c) Austausch im selben Ordner, alte Installation beiseitelegen.
C) Seite kurz vom Netz, wenn weder A noch B heute möglich ist und Kundendaten auf der Seite liegen.
Nenne zu jeder Variante Aufwand, Nebenwirkungen und den Rückweg. Empfiehl eine. Weise mich darauf hin, dass ich das mit der Person abstimmen sollte, die meine Seite gebaut hat oder betreut, und dass ohne diese Begleitung alles auf eigene Gefahr geschieht.

Schritt 4, erst nach meiner Entscheidung ausführen: Zuerst die Sicherung (Dateien und Datenbank, bevorzugt über die Sicherungsfunktion des Hosters, sonst per Download), dann der gewählte Weg Schritt für Schritt. Bei B: Prüfe zuerst, was nicht statisch funktioniert, und schlage je Punkt einen Ersatz vor (Formular → Mail-Link und Telefonnummer, Shop → Hinweis „Bestellung per Telefon oder E-Mail“); erzeuge dann eine vollständige statische Kopie (alle Seiten, Bilder, Stylesheets, Schriften, relative Links, zum Beispiel mit wget --mirror oder httrack); prüfe die Kopie lokal im Browser und zeige mir, was fehlt oder kaputt ist; erkläre mir das Hochladen, das Scharfschalten über den gewählten Weg, das Abschalten von PHP und den Rückweg.

Schritt 5, Abschluss: Fasse auf einer halben Seite zusammen, was jetzt läuft, was fehlt, was ich meinem Hoster oder meiner Agentur schreiben soll, und wann ich zurückschalten kann.

Du bist mein IT-Helfer, ich bin kein Techniker. Erkläre alles ohne Fachjargon und frag mich vor jedem Schritt. Lösche und verändere nichts auf dem Server.

Meine Website: [Adresse, z. B. https://www.meine-firma.de]
System: [WordPress / TYPO3 / Joomla / weiß ich nicht]
Hoster: [z. B. IONOS, Strato, All-Inkl / eigener Server]
Ziel: Eine vollständige Sicherung meiner Website auf meinem eigenen Rechner, bevor ich wegen der PHP-Sicherheitslücke „PHP2Shell“ (21.10.2026) etwas umstelle.

Bitte gehe so vor:
1. Lege auf meinem Rechner einen Ordner „Sicherung-[heutiges Datum]“ an und erkläre mir kurz, was alles gesichert werden muss: die Dateien der Website (Texte, Bilder, Themes, Plugins, Konfigurationsdatei) und die Datenbank.
2. Dateien: Zeige mir, wie ich sie herunterlade, entweder über den SFTP- oder FTP-Zugang meines Hosters oder als Download im Hosting-Panel. Wenn Zugangsdaten nötig sind, sag mir, wo ich sie auf meinem Rechner eingebe. Ich schreibe sie nicht in den Chat.
3. Datenbank: Zeige mir, wie ich sie exportiere, meist über das Hosting-Panel oder phpMyAdmin; bei einem eigenen Server mit mysqldump. Die Export-Datei kommt in denselben Ordner.
4. Prüfe die Sicherung auf Vollständigkeit: Anzahl und Gesamtgröße der Dateien, ob die Datenbank-Datei nicht leer ist, ob die Konfigurationsdatei dabei ist (bei WordPress wp-config.php).
5. Fasse am Ende zusammen: Was ist gesichert, wo liegt es, was fehlt noch. Auf dem Server bleibt alles, wie es war.

Du bist mein IT-Helfer für meinen eigenen Server, ich bin kein Administrator. Erkläre mir jeden Befehl, bevor du ihn ausführst, und frag mich vor jedem Schritt. Nichts ohne Sicherung.

Mein Server: [Ubuntu / Debian / Plesk / cPanel / Docker / weiß ich nicht]
Webserver: [Apache / nginx / weiß ich nicht]
Website darauf: [Adresse, System, z. B. WordPress]
Ziel: Die PHP-Sicherheitslücke „PHP2Shell“ (CVE-2026-109618 und CVE-2026-109619, 21.10.2026) auf diesem Server schließen.

Bitte gehe so vor:
1. Stelle fest, welche PHP-Version läuft und in welcher Betriebsart (mod_php oder PHP-FPM). Erkläre mir, was das für mich bedeutet.
2. Prüfe, ob eine aktuelle Sicherung vorhanden ist (Dateien, Datenbank, Konfiguration). Wenn nicht: erst sichern, dann weiter.
3. Aktualisiere PHP über die Pakete meiner Distribution. Ziel ist 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, oder die nachgebesserte Fassung (Backport), die meine Distribution für ihre PHP-Version anbietet. Bei Docker: das Image erneuern.
4. Falls das Paket noch nicht verfügbar ist: Setze die Übergangswerte aus der offiziellen PHP-Sicherheitsmeldung, mindestens session.upload_progress.enabled = 0 und ein kleines post_max_size, und erkläre mir, dass das nur bis zum Update gilt.
5. Starte danach ALLE PHP-Prozesse wirklich neu, also Webserver und PHP-FPM. Ein „graceful“-Neustart reicht nicht.
6. Prüfe die laufende Version über einen Seitenaufruf (etwa eine phpinfo-Seite, die du danach wieder löschst), nicht nur auf der Kommandozeile.
7. Sieh die Protokolle von Webserver und PHP auf Spuren durch: gehäufte Fehler 500, Meldungen zum Speicherlimit, ungewöhnlich große Sitzungs-Cookies, ständig neu startende PHP-Prozesse. Zeige mir, was du findest, und bewerte es nüchtern.
8. Erinnere mich danach daran, die Passwörter und Schlüssel zu wechseln, die der Server kennt (Datenbank, Mail, API-Schlüssel, Zertifikate), und schlage mir eine Reihenfolge vor.
9. Fasse am Ende zusammen: Version vorher und nachher, welche Werte gesetzt sind, was in den Protokollen stand, was noch offen ist.

Was eine statische Seite sonst noch bringt

Eine statische Seite ist keine Notlösung, sondern ein eigenes Prinzip. Diese Seite hier läuft so. Was es bringt, nüchtern aufgezählt:

• Schneller: Der Server muss nichts zusammenbauen, er liefert fertige Seiten aus.
• Weniger Angriffsfläche, dauerhaft: Ohne PHP, Plugins und Datenbank fällt das meiste weg, was sonst gepatcht werden muss.
• Kaum Wartung: Keine Updates von System, Theme und Plugins, die sich gegenseitig im Weg stehen.
• Günstiger im Betrieb: Ein kleines Hosting-Paket reicht in der Regel.

Wie sich das in Zahlen zeigt: Diese Website hier ist seit dem Neuaufbau statisch. So sah Googles PageSpeed-Test für die Startseite am 21. Oktober 2026 um 19:37 Uhr aus (Handy-Messung):

Nach der Lage kann man das statische Prinzip dauerhaft übernehmen: Was heute die Übergangslösung ist, wird dann die eigentliche Website. Wer das für seine Seite möchte, darf mir schreiben, riedel@riedelit.de, Betreff „Website statisch machen“.

Ich antworte in der Reihenfolge des Eingangs und sage Ihnen ehrlich, ob und wann ich es übernehmen kann.

Drei Fragen, die mir heute am häufigsten gestellt wurden

Muss ich meine Seite wirklich abschalten?

Nein, nicht als Erstes. Die Reihenfolge ist: Sicherung, PHP-Version umstellen, durchklicken. Abschalten ist nur die Notbremse, wenn das Update nicht geht und die Seite Kundendaten, Logins oder einen Shop hat. Und selbst dann ist die Web-Visitenkarte meist besser als eine leere Seite. Die britische Behörde NCSC sagt es genauso: offline nehmen nur als letztes Mittel.

Wenn jemand auf dem Webserver ist, kann er dann auch meine E-Mails lesen?

Nicht automatisch, aber oft über Umwege. Der Angreifer bekommt die Rechte Ihrer Website, nicht die Ihres Postfachs. Bei einem Hosting-Paket liegen Website und Postfächer meist auf getrennten Systemen; dann kommt er an die Mails nicht direkt heran. Drei Umwege sind aber real: Erstens, wenn Ihre Website selbst Mails verschickt (Kontaktformular, Shop, WordPress mit SMTP-Plugin), steht das Passwort dieses Postfachs in der Konfiguration oder im Arbeitsspeicher, und genau den kann die Lücke verraten. Zweitens, wenn Sie Webmail (etwa Roundcube) auf demselben Server betreiben, läuft die mit PHP und ist selbst betroffen. Drittens, wenn Sie für Website und Postfach dasselbe Passwort benutzen. Deshalb nach einem Einbruch: das Passwort jedes Postfachs ändern, das die Website kennt, Weiterleitungsregeln und den Ordner „Gesendet“ auf Fremdes prüfen, Zwei-Faktor-Anmeldung fürs Postfach einschalten. Und ohne Einbruch? In der Ruhe liegt die Kraft: erst das Update, dann in den nächsten Tagen die Passwörter wechseln, die die Website kennt, eines nach dem anderen, mit Notiz, wo es überall eingetragen ist. Hektisch heute Nacht alles auf einmal zu ändern bringt mehr Aussperrungen als Sicherheit. Ihre Mail-Zustellung (DNS, MX) bleibt davon unberührt, solange nicht auch der Hosting-Zugang selbst erbeutet wurde.

Reicht es, wenn WordPress oder der Shop im Wartungsmodus ist?

Nein. Der Wartungsmodus ist eine Seite, die PHP anzeigt; PHP verarbeitet weiter jede Anfrage, auch die des Angreifers. Schutz gibt es nur ohne PHP (statische Kopie), mit gesperrten Uploads am Webserver oder ganz vom Netz.

Textvorlage: So fragen Sie Hoster oder Agentur

Kopieren, Namen einsetzen, abschicken. Mehr braucht es nicht.

Wo ich die Lage verfolge

Diese Stellen dokumentieren den Verlauf laufend und nüchtern, alle am 21. Oktober von mir gelesen. Wenn Sie nur eine lesen wollen: die erste.

• BSI: Pressemitteilung zur PHP-Schwachstelle und die Cybersicherheitswarnung (PDF, Kritikalität „sehr hoch“, wird versioniert fortgeschrieben). Deutsch, amtlich, nüchtern.
• PHP-Projekt: offizielle Sicherheitsmeldung, die Quelle für Versionsnummern, Betroffenheit und alle Übergangseinstellungen (englisch).
• SANS Internet Storm Center, das Frühwarnzentrum hat die Alarmstufe auf Gelb gesetzt und aktualisiert den Eintrag laufend (englisch).
• NCSC-NL: Software-Inventar „php2shell“, die niederländische Behörde pflegt wie bei Log4Shell eine Liste, welche Produkte (Plesk, QNAP, Synology, Shopware …) betroffen sind (englisch).
• Sansec: PHP2Shell, Zeitleiste, Gegenmaßnahmen und Erkennungszeichen der Shop-Sicherheitsfirma, die als eine der ersten berichtet hat (englisch).
• Cloudflare-Blog, die einzige Stelle mit Blick auf echten Angriffsverkehr, dazu die Schutzregeln (englisch).
• Wiz Research, Mitentdecker, technische Einordnung und Erkennungszeichen (englisch).
• heise online, deutschsprachige Einordnung mit Zitaten des PHP-Teams.
• Deutschland sicher im Netz, Handlungsempfehlungen für kleine Betriebe in einfacher Sprache.

Noch offen (Stand 18:20 Uhr): Statusmeldungen der großen deutschen Hoster (IONOS, Strato, All-Inkl, Hetzner, netcup, Mittwald, Hosteurope) habe ich noch nicht gefunden; Plesk- und cPanel-Pakete waren am Nachmittag angekündigt, aber noch nicht ausgeliefert. Ich trage es nach.

Ein offenes Wort: Wer Ihnen heute helfen kann

Bei meinen Bestandskunden melde ich mich in diesen Tagen selbst, oder Sie erreichen mich wie gewohnt. Neue Aufträge zu dieser Lücke kann ich derzeit nicht annehmen; ich bin ein Einzelbetrieb, und die Kapazität gehört den Kunden, die ich schon betreue. Einzige Ausnahme: das statische Umstellen einer Website, dazu dürfen Sie mir schreiben. Diese Seite ist deshalb meine Hilfe für alle anderen: Teilen Sie sie, drucken Sie sie, schicken Sie die Textvorlage an Ihren Hoster. Die richtigen Ansprechpartner sind heute: Ihr Hoster (Support-Ticket, Statusseite), Ihre Agentur oder der Dienstleister, der die Seite gebaut hat, bei einem Einbruch mit Personendaten zusätzlich Ihr Datenschutzbeauftragter. Das BSI bietet für kleine Betriebe die Informationen und Empfehlungen für Unternehmen.