Kurz gesagt: Das CMS nach einem Hack zu wechseln hilft nur, wenn das alte System selbst die Ursache war, etwa weil der Hersteller keine Sicherheitsupdates mehr liefert oder wichtige Erweiterungen nicht mehr gepflegt werden. Lag die Ursache in veralteten Plugins, schwachen Zugängen oder einer Lücke wie PHP2Shell im darunterliegenden PHP, verschiebt ein Wechsel nur den Aufwand. In jedem Fall gilt: Inhalte erst prüfen, dann umziehen, sonst wandert der Schadcode mit.
Wenn das Vertrauen weg ist
Nach einem Einbruch ist die Stimmung oft eindeutig: „Mit diesem System nie wieder.“ Das ist verständlich. Die Website hat Besucher auf fremde Seiten umgeleitet, Google hat gewarnt, Kunden haben nachgefragt. Ein neues CMS fühlt sich wie ein Neuanfang an.
Die Lage um PHP2Shell zeigt aber, warum dieser Reflex in die Irre führen kann. Die Lücke steckt im PHP-Interpreter, nicht in WordPress, TYPO3, Shopware oder einem anderen System. WordPress.org plant laut drweb.de deshalb kein eigenes Update dagegen. Wer jetzt von einem PHP-CMS auf ein anderes PHP-CMS wechselt, hat am Ende dieselbe Abhängigkeit, nur mit anderem Logo. Welche Systeme auf PHP laufen, zeigt die Übersicht Welche CMS und Shopsysteme auf PHP laufen.
Was die Ursache war, entscheidet
Bevor Sie über einen Wechsel nachdenken, muss die Ursache des Einbruchs geklärt sein. Typische Einfallstore sind veraltete Erweiterungen, mehrfach verwendete oder schwache Passwörter, fehlende Zwei-Faktor-Anmeldung, ein ungepatchter Server oder vergessene Testinstallationen. Keine dieser Ursachen ist an ein bestimmtes CMS gebunden.
Wer die Ursache nicht kennt, riskiert, sie ins neue System mitzunehmen. Ein Team, das Updates bisher aufgeschoben hat, wird das im neuen CMS ebenso tun. Eine Agentur, die gemeinsame Admin-Konten nutzte, wird das wiederholen, wenn niemand den Ablauf ändert. Die Frage ist also weniger „welches CMS?“, sondern „welcher Prozess?“.
CMS wechseln nach dem Hack: die Abwägung
| Kriterium | Beim bestehenden CMS bleiben und härten | Auf ein anderes CMS wechseln |
|---|---|---|
| Ursache des Einbruchs | Bekannt und behebbar, etwa veraltetes Plugin | Liegt im System selbst, etwa fehlende Herstellerupdates |
| Herstellerpflege | Sicherheitsupdates werden geliefert | Hersteller hat die Pflege eingestellt |
| Abhängigkeit von Erweiterungen | Wenige, gepflegte Erweiterungen | Viele Erweiterungen ohne aktive Pflege |
| Aufwand | Bereinigung, Härtung, Prozessänderung | Neuaufbau, Migration, Schulung, oft Neugestaltung |
| Zeit bis zur sicheren Website | Kürzer | Länger, Übergangslösung nötig |
| Schutz vor PHP-Lücken | Keine Änderung, PHP muss gepatcht werden | Keine Änderung, solange das neue System PHP nutzt |
| Langfristiger Nutzen | Hoch, wenn Prozesse verbessert werden | Hoch, wenn das alte System ohnehin am Ende war |
Wenn die meisten Zeilen in Ihrer Lage links landen, lohnt sich der Wechsel kaum. Bleiben, bereinigen, härten und den Wartungsablauf verbessern bringt mehr Sicherheit für weniger Geld. Für WordPress-Betreiber fasst WordPress und PHP2Shell die wichtigsten Schritte zusammen.
Einen Dienstleister brauchen Sie für diese Entscheidung nicht immer. War die Ursache eindeutig, etwa ein bekanntes Plugin mit veröffentlichter Lücke, und hat Ihre Agentur oder Ihr Admin die Website sauber neu aufgesetzt, können Sie selbst entscheiden. Externe Hilfe lohnt sich, wenn die Ursache unklar bleibt oder personenbezogene Daten betroffen sein könnten.
Wenn Sie wechseln: den Schadcode nicht mitnehmen
Fällt die Entscheidung für einen Wechsel, ist die Migration selbst ein Sicherheitsrisiko. Angreifer hinterlassen Spuren nicht nur in Dateien, sondern auch in der Datenbank. Diese Schritte helfen, sauber umzuziehen:
- Altes System sichern und isolieren: Vollständige Sicherung als Beweis, dann das alte System vom Netz nehmen oder nur noch intern erreichbar machen.
- Inhalte gezielt exportieren: Texte, Seitenstruktur und Medien, nicht die komplette Datenbank. Benutzerkonten nicht übernehmen, sondern neu anlegen.
- Inhalte prüfen: Texte auf eingeschleuste Skripte, versteckte Links und fremde Weiterleitungen durchsehen. Wie das geht, beschreibt Die Datenbank auf eingeschleusten Code prüfen.
- Medien filtern: Nur erwartete Dateitypen übernehmen, Dateien mit doppelten Endungen oder Skriptinhalt aussortieren.
- Neues System sauber aufsetzen: Aus der Originalquelle des Herstellers, auf einem Server mit gepatchtem PHP, mit neuen Zugangsdaten und Zwei-Faktor-Anmeldung.
- Weiterleitungen planen: Alte Adressen auf neue umleiten, damit Suchmaschinen und Besucher ankommen, ohne dass alte Pfade offen bleiben.
Ein CMS-Wechsel ersetzt keine Bereinigung des alten Servers. Läuft das alte System weiter, etwa als vergessene Kopie unter einer Subdomain, bleibt die Hintertür offen.
Die Alternative, die oft übersehen wird
Manche Unternehmen stellen nach einem Hack fest, dass sie die Funktionen eines grossen CMS gar nicht brauchen. Eine Firmenwebsite mit wenigen Seiten, die selten geändert werden, kommt auch ohne PHP auf dem Server aus. Ein Generator für statische Seiten erzeugt fertige HTML-Dateien, die keine serverseitige Programmlogik mehr benötigen. Welche Vor- und Nachteile das hat, beschreibt Statische Websites: Weniger PHP, weniger Angriffsfläche.
Umgekehrt ist das für Shops, Portale oder Websites mit vielen Redakteuren meist keine Option. Hier bleibt ein dynamisches System sinnvoll, und die Sicherheit entsteht durch Pflege, Härtung und Überwachung.
Wer unsicher ist, ob im alten WordPress noch versteckte Zugänge lauern, findet in Backdoors in WordPress finden die typischen Fundstellen. Das hilft auch bei der Entscheidung, ob eine Bereinigung realistisch ist.
Wie hilft PHP SOS konkret?
- Wir klären zuerst die Ursache des Einbruchs und sagen Ihnen, ob sie am CMS liegt oder an Prozess und Server.
- Wir bereinigen das bestehende System im Rahmen der Malware-Entfernung oder bereiten es als Beweis für einen Neuaufbau vor.
- Bei einem Wechsel prüfen wir die zu übernehmenden Inhalte und Medien auf Schadcode, bevor sie ins neue System gelangen.
- Wir setzen den neuen Server mit gepatchtem PHP und gehärteter Konfiguration auf.
Fazit
Ein CMS-Wechsel nach einem Hack ist selten die Lösung, aber manchmal der richtige Anlass. Wenn das alte System nicht mehr gepflegt wird, lohnt der Neuanfang. Wenn die Ursache in Prozessen oder im Server lag, bringt die Arbeit am Prozess mehr als ein neues Logo. In beiden Fällen gilt: Erst prüfen, dann umziehen.
Häufige Fragen
Hilft ein CMS-Wechsel gegen PHP2Shell?
Nein, solange das neue CMS ebenfalls auf PHP läuft. PHP2Shell steckt im PHP-Interpreter, nicht im CMS. Entscheidend ist der Patch-Stand von PHP auf dem Server, nicht das System darüber.
Ist WordPress unsicherer als andere CMS?
Pauschal lässt sich das nicht sagen. Viele Einbrüche entstehen durch veraltete Erweiterungen, schwache Zugänge oder fehlende Updates, und diese Ursachen gibt es in jedem System. Die Verbreitung macht ein CMS allerdings zu einem häufigeren Ziel automatisierter Scans.
Kann ich Inhalte aus dem gehackten CMS einfach exportieren?
Nur nach Prüfung. Die Datenbank kann eingeschleuste Skripte, versteckte Links oder fremde Admin-Konten enthalten. Hochgeladene Dateien können Schadcode tarnen. Exportieren Sie Inhalte gezielt und prüfen Sie sie vor dem Import.
Wann ist ein CMS-Wechsel wirklich sinnvoll?
Wenn der Hersteller keine Sicherheitsupdates mehr liefert, wenn die Website auf Erweiterungen angewiesen ist, die nicht mehr gepflegt werden, oder wenn das System für die heutigen Anforderungen schlicht nicht mehr passt. Der Hack ist dann der Anlass, nicht der Grund.