Kurz gesagt: Wer nach einem Sicherheitsvorfall den Hoster wechseln will, sollte zuerst Beweise sichern und den Vorfall klären, dann nur geprüfte Daten auf ein neu aufgesetztes System übertragen und erst danach den alten Vertrag beenden. Den neuen Anbieter wählen Sie nach Sicherheitskriterien: belegbare Patch-Abläufe, Trennung der Kunden, Zugriff auf Logs, Backups und klare Ansprechpartner. Ein Hoster-Wechsel ist sinnvoll, wenn Vertrauen oder Leistung fehlen, er ersetzt aber keine Bereinigung.
Wenn das Vertrauen weg ist
Nach PHP2Shell erleben viele Unternehmen ihren Hoster zum ersten Mal unter Druck. Manche bekamen schnell eine klare Auskunft über den Patchstand. Andere warteten Tage auf eine Antwort, erhielten nur allgemeine Formeln oder stellten fest, dass ihre Website auf einer veralteten PHP-Version lief. Kommt dann noch ein Vorfall hinzu, ist der Wunsch nach einem Wechsel verständlich.
Ein Hoster-Wechsel ist aber kein Schritt der Vorfallbewältigung, sondern der Neuaufstellung danach. Wer ihn in die falsche Reihenfolge bringt, nimmt im schlechtesten Fall den Angreifer mit und verliert gleichzeitig die Spuren, die zeigen, was passiert ist.
Die richtige Reihenfolge beim Wechsel
- Spuren sichern, solange sie da sind. Logs, Dateien und Datenbank des alten Systems gehören in eine Sicherung, bevor etwas gelöscht oder gekündigt wird. Fragen Sie den alten Hoster ausdrücklich nach Zugriffs- und Fehlerlogs ab dem 20. Oktober 2026 und nach deren Aufbewahrungsdauer. Wie Sie dabei vorgehen, beschreibt der Beitrag Beweise sichern, bevor Sie neu aufsetzen.
- Vorfall eingrenzen. Welche Systeme sind betroffen, welche Zugänge wurden genutzt, welche Daten waren erreichbar? Davon hängen Meldepflichten und die Frage ab, was Sie mitnehmen dürfen.
- Meldepflichten prüfen. Können personenbezogene Daten betroffen sein, beginnt die Frist für eine mögliche DSGVO-Meldung mit Kenntnis des Vorfalls, nicht mit dem Umzug. Hintergründe stehen unter DSGVO-Meldepflicht: 72 Stunden.
- Neues System sauber aufbauen. Unterstützte PHP-Version, aktuelle Pakete, gehärtete Konfiguration, bevor die erste Datei übertragen wird.
- Nur Geprüftes übertragen. Code aus sauberer Quelle, Datenbank und Medien nach Kontrolle.
- Alle Zugangsdaten wechseln. Datenbank, Admin-Konten, SSH, FTP, API-Schlüssel, auch die in Konfigurationsdateien.
- Umschalten und beobachten. DNS-Umstellung, danach eine Zeit lang engere Überwachung.
- Alten Vertrag beenden. Erst wenn Logs und Sicherungen gesichert sind und der neue Betrieb stabil läuft.
Kündigen Sie den alten Vertrag nicht, bevor Sie Logs und Sicherungen in der Hand haben. Mit dem Vertragsende können Daten beim Anbieter gelöscht werden, die Sie für Versicherer, Behörden oder die eigene Aufklärung brauchen.
Was Sie nicht mitnehmen sollten
Bequem wäre es, das komplette Webverzeichnis oder ein Abbild des Servers einfach zu kopieren. Genau das ist nach einem Vorfall riskant. Webshells tarnen sich als harmlose Dateien, Hintertüren stecken in Konfigurationsdateien wie .htaccess oder .user.ini, und eingeschleuster Code kann in Datenbankinhalten liegen.
Übertragen Sie den Anwendungscode deshalb aus einer sauberen Quelle, etwa dem Herstellerpaket in der passenden Version oder Ihrem Versionsverwaltungssystem. Medien übernehmen Sie ohne ausführbare Dateien, die Datenbank nach einer Kontrolle auf auffällige Inhalte und neue Administratorkonten. Was auf dem alten System gefunden wurde, hilft bei dieser Kontrolle.
Denken Sie auch an alles, was neben der Website beim alten Anbieter liegt. E-Mail-Postfächer, DNS-Einträge, Zertifikate und Weiterleitungen werden beim Umzug leicht vergessen. Senken Sie die Gültigkeitsdauer der DNS-Einträge einige Tage vor dem Umschalten, damit die Umstellung schnell bei den Besuchern ankommt. Ziehen E-Mails mit um, planen Sie den Wechsel der Postfächer gesondert, denn auch dort können nach einem Vorfall Zugangsdaten betroffen sein.
Den neuen Hoster nach Sicherheit auswählen
Preis und Speicherplatz stehen in jedem Angebot. Die entscheidenden Sicherheitsfragen müssen Sie meist selbst stellen. Die folgende Liste hilft beim Vergleich:
| Kriterium | Frage an den Anbieter | Warum es zählt |
|---|---|---|
| Patch-Ablauf | Wie und in welchem Rahmen werden PHP-Sicherheitsupdates eingespielt und neu gestartet? | PHP2Shell hat gezeigt, wie wichtig ein belegbarer Ablauf ist |
| Nachweis | Erhalte ich auf Anfrage eine schriftliche Bestätigung zum Patchstand? | Grundlage für Ihre eigene Dokumentation |
| PHP-Versionen | Welche Zweige werden angeboten, wie lange noch? | Alte Zweige ohne Updates sind ein Dauerrisiko |
| Trennung | Läuft jede Website mit eigenem Benutzer und eigenem PHP-Prozess? | Begrenzt Schäden, wenn ein Nachbar angegriffen wird |
| Logs | Habe ich Zugriff auf Zugriffs- und Fehlerlogs, wie lange werden sie aufbewahrt? | Ohne Logs keine Aufklärung |
| Backups | Wie oft, wie lange, getrennt vom Webserver, mit Wiederherstellungstest? | Wiederherstellung nach einem Vorfall |
| Notfallkontakt | Wie erreiche ich bei einem Vorfall eine fachkundige Person? | Zeit ist im Ernstfall der knappste Faktor |
| Auftragsverarbeitung | Gibt es einen Vertrag nach DSGVO und eine Liste der Unterauftragnehmer? | Pflicht bei personenbezogenen Daten |
Eine Vorlage für die Frage nach dem Patchstand bietet der Ratgeber Hoster nach dem Patch-Status fragen. Sie eignet sich auch, um Anbieter vor dem Vertragsschluss zu vergleichen.
Ist ein anderes Betriebsmodell die bessere Antwort?
Manchmal liegt das Problem weniger beim Hoster als beim Betriebsmodell. Wer einen eigenen Server ohne regelmäßige Pflege betreibt, ist mit einem gut betreuten Managed-Angebot oft besser aufgehoben. Umgekehrt kann ein Unternehmen mit eigener IT mehr Kontrolle über Patch-Zeitpunkte gewinnen, wenn es selbst verwaltet. Die Abwägung beschreibt der Beitrag Managed Hosting oder eigener Server?.
Unabhängig vom Modell gilt: Halten Sie die Aufgabenteilung schriftlich fest. Wer spielt PHP-Updates ein, wer startet neu, wer prüft die Anwendung, wer meldet sich im Notfall bei wem? Bei PHP2Shell sind viele Verzögerungen genau an dieser Stelle entstanden, weil jede Seite dachte, die andere kümmere sich.
Wie hilft PHP SOS konkret?
- Wir sichern Logs und Daten des alten Systems und klären, was beim Vorfall passiert ist.
- Wir bauen das neue System gehärtet auf und übertragen nur geprüfte Inhalte aus sauberen Quellen.
- Wir prüfen Angebote neuer Anbieter anhand der Sicherheitskriterien und stellen die richtigen Fragen.
- Bei einem laufenden Vorfall arbeiten wir im Rahmen unserer Incident Response, bis der Vorfall abgeschlossen und dokumentiert ist.
Häufige Fragen
Sollte ich nach einem Hack sofort den Hoster wechseln?
Nicht sofort. Zuerst müssen Spuren gesichert, der Vorfall eingegrenzt und die Ursache geklärt werden. Ein überstürzter Umzug nimmt Schadcode womöglich mit und kann Beweise beim alten Anbieter vernichten.
War der Hoster schuld, wenn meine Website über PHP2Shell angegriffen wurde?
Das hängt vom Vertrag und vom Zeitpunkt ab. Beim Shared Hosting ist meist der Hoster für PHP-Updates zuständig, bei eigenen Servern der Betreiber. Die Patches erschienen am 21. Oktober 2026; ob und wann sie eingespielt wurden, lässt sich nur mit Belegen klären. Für Haftungsfragen ziehen Sie anwaltlichen Rat hinzu.
Welche Daten darf ich zum neuen Hoster mitnehmen?
Nur geprüfte Inhalte: Datenbank nach Kontrolle auf eingeschleusten Code, Medien ohne ausführbare Dateien und Code aus einer sauberen Quelle wie dem Herstellerpaket oder Ihrem Versionsverwaltungssystem. Komplette Server-Abbilder oder Webverzeichnisse vom kompromittierten System sollten Sie nicht ungeprüft übertragen.
Muss ich nach einem Vorfall den Datenschutz einbeziehen?
Wenn personenbezogene Daten betroffen sein können, kann eine Meldepflicht nach DSGVO bestehen, in der Regel binnen 72 Stunden. Beim neuen Hoster brauchen Sie außerdem einen Vertrag zur Auftragsverarbeitung. Klären Sie das mit Ihrem Datenschutzbeauftragten; dies ist keine Rechtsberatung.