WordPress: vom Einstieg bis zur Entwicklung · Modul 5: Fehlerbehebung und Betrieb

Lektion 4 von 5Text 15 Min.

Gehackte Website bereinigen

Lernziele
  • Anzeichen einer kompromittierten Website erkennen
  • einen Vorfall in der richtigen Reihenfolge abarbeiten
  • die Einstiegsstelle finden, statt nur aufzuräumen
  • rechtliche Pflichten nach einem Vorfall einschätzen

Websites werden fast nie gezielt angegriffen – sie geraten in automatisierte Scans, die tausende Adressen pro Stunde nach bekannten Lücken absuchen. Ein veraltetes Plugin, ein schwaches Passwort, ein offenes Formular: Das genügt. Wer den Ernstfall einmal durchdacht hat, verliert im Fall der Fälle keine Zeit mit Panik. Diese Lektion beschreibt einen geordneten Ablauf: erkennen, sichern, bereinigen, absichern, beobachten – und die Frage, welche Pflichten dabei entstehen.

1. Erkennen

ChecklisteAnzeichen für eine kompromittierte Website
0 von 6 geöffnet. Schon ein einziges Anzeichen genügt, um die Website als kompromittiert zu behandeln – suchen Sie nicht nach Bestätigung, sondern handeln Sie.

Besonders tückisch ist Schadcode, der sich je nach Besucher anders verhält: Für angemeldete Personen sieht die Website normal aus, nur Besucher aus der Google-Suche werden weitergeleitet. Prüfen Sie deshalb immer auch in einem privaten Fenster und mit einer Google-Suche nach site: gefolgt von der Domain – dort zeigen sich fremde Seiten oft zuerst.

2. Die Reihenfolge im Ernstfall

Klick-GrafikEinen Vorfall abarbeiten
SichernOfflineZugängeBereinigenLücke schließen
Schritt 1/5 · Sichern: Zuerst eine vollständige Sicherung von Dateien und Datenbank anlegen – auch im infizierten Zustand. Sie ist Beweismittel und Rettungsanker, falls beim Aufräumen etwas schiefgeht.

Der wichtigste und am häufigsten übersprungene Schritt ist der letzte. Wer nur aufräumt, ohne die Ursache zu finden, hat in wenigen Tagen dasselbe Problem. Typische Einstiegsstellen sind ein Plugin mit bekannter Lücke, ein schwaches oder wiederverwendetes Passwort, eine veraltete PHP-Version und Dateien aus zweifelhaften Quellen, etwa freigeschaltete Bezahl-Themes.

Verdächtige Dateien finden (SSH)
1# PHP-Dateien im Upload-Ordner – dort gehört niemals PHP hin
2find wp-content/uploads -name "*.php"
3
4# Zuletzt geänderte Dateien der vergangenen drei Tage
5find . -type f -mtime -3 -name "*.php" | head -50
6
7# Typische Tarnfunktionen suchen
8grep -rn --include="*.php" -E "eval\(|base64_decode\(|gzinflate\(" wp-content | head
9
10# Kerndateien mit dem Original vergleichen
11wp core verify-checksums

3. Bereinigen oder neu aufbauen?

Bei einem klaren, früh entdeckten Befall genügt oft das Ersetzen der Dateien. Steckt der Schadcode tief, sind Kerndateien verändert und liegt der Einstieg Wochen zurück, ist ein Neuaufbau meist schneller und sicherer: frische WordPress-Installation, Plugins und Themes neu aus offizieller Quelle, Inhalte gezielt übernehmen und den Ordner uploads sorgfältig prüfen. Eine ältere Sicherung von vor dem Vorfall einzuspielen ist verlockend, löst das Problem aber nur, wenn die Lücke danach geschlossen wird – und die Inhalte seitdem verlorene Tage kosten.

Tab. 4.1Nach dem Vorfall absichern
MaßnahmeWirkung
Automatische Updates für Sicherheitsversionenschließt bekannte Lücken ohne Verzögerung
Zwei-Faktor-Anmeldung für alle Administratorenverhindert Anmeldungen mit gestohlenen Passwörtern
Ausführung von PHP in uploads sperrenmacht hochgeladene Schadskripte wirkungslos
Dateibearbeitung im Backend abschalten (DISALLOW_FILE_EDIT)entzieht Angreifern ein bequemes Werkzeug
Anmeldeversuche begrenzen, Protokollierungerschwert das Durchprobieren von Passwörtern
Regelmäßige, getrennt gespeicherte Backupsermöglicht eine schnelle Rückkehr in den Normalzustand
Sichern, offline nehmen, Zugänge erneuern, bereinigen, Lücke schließen. Ohne den letzten Schritt ist die Arbeit umsonst.

4. Pflichten nach einem Vorfall

Ein Angriff ist nicht nur ein technisches Problem. Wenn personenbezogene Daten betroffen sein könnten – Kundenkonten, Bestellungen, Formularnachrichten, Newsletter-Adressen –, greift die Datenschutz-Grundverordnung: Der Vorfall ist in der Regel binnen 72 Stunden der zuständigen Aufsichtsbehörde zu melden, und bei hohem Risiko müssen auch die Betroffenen informiert werden. Dokumentieren Sie deshalb von Anfang an: Wann wurde was entdeckt, welche Daten liegen auf dem System, welche Schritte wurden wann unternommen. Diese Dokumentation ist Pflicht und hilft zugleich, den Überblick zu behalten. Bei Spam-Versand sollte außerdem der Hoster informiert werden, und in der Search Console lässt sich nach der Bereinigung eine erneute Prüfung beantragen, damit die Warnung im Suchergebnis verschwindet.

5. Ein Beispiel

Eine Zahnarztpraxis bemerkte nichts, bis Patienten anriefen: Wer die Praxis googelte und auf das Ergebnis klickte, landete auf einer fremden Seite. Angemeldet war die Website unauffällig. Der Hoster meldete zugleich massenhaften Mailversand. Nach der Sicherung wurde die Website offline genommen, alle Zugänge erneuert und der Kern neu eingespielt. Im Ordner uploads fanden sich drei PHP-Dateien mit harmlos klingenden Namen. Die Einstiegsstelle war ein seit zwei Jahren nicht aktualisiertes Formular-Plugin mit bekannter Lücke. Nach der Bereinigung folgten Zwei-Faktor-Anmeldung, automatische Sicherheitsupdates, eine Sperre für PHP in uploads und ein monatlicher Wartungstermin. Weil nur Kontaktnachrichten betroffen waren, wurde der Vorfall dokumentiert und gemeldet; die Praxis informierte die betroffenen Personen zusätzlich von sich aus.

6. Häufige Fragen

Reicht ein Sicherheits-Plugin? Es hilft beim Erkennen und erschwert Angriffe, ersetzt aber keine Updates und keine guten Passwörter. Ein Scanner findet zudem nicht jeden Schadcode – ein negativer Befund ist kein Beweis für Sauberkeit.

Kann ich einfach ein Backup einspielen? Nur, wenn es sicher aus der Zeit vor dem Vorfall stammt und die Lücke danach geschlossen wird. Sonst wiederholt sich alles. Prüfen Sie, wie weit die Sicherungen zurückreichen – viele Hoster bewahren nur sieben Tage auf.

Wer haftet? Verantwortlich für die Website ist der Betreiber. Wer die Pflege beauftragt, sollte vertraglich festhalten, wer Updates einspielt, wie schnell Sicherheitslücken geschlossen werden und wie Backups organisiert sind.

7. Übung zum Selbermachen

Schreiben Sie eine Notfallkarte für eine Website, die Sie betreuen: Wo liegen Zugangsdaten, wer ist beim Hoster Ansprechpartner, wo liegen Backups und wie alt sind sie, wer muss informiert werden, welche personenbezogenen Daten liegen auf dem System. Prüfen Sie anschließend drei Dinge praktisch: Lässt sich eine Sicherung tatsächlich wiederherstellen? Gibt es PHP-Dateien im Ordner uploads? Wie viele Administratorkonten existieren und werden alle noch gebraucht?

Quellen und weiterführende Literatur
  1. [1]WordPress.org (2026): FAQ My Site Was Hacked; Hardening WordPress – Advanced Administration Handbook.
  2. [2]BSI (2025): Maßnahmenkatalog für Webseitenbetreiber; Reaktion auf IT-Sicherheitsvorfälle.
  3. [3]Art. 33, 34 DSGVO – Meldung von Verletzungen des Schutzes personenbezogener Daten.

Stand: September 2026, WordPress 7.1, PHP 8.3. Kursmaterial der Klarwerk Akademie. WordPress entwickelt sich schnell – maßgeblich ist die aktuelle Dokumentation auf developer.wordpress.org.

Abschlussquiz

Drei Fragen – dann ist die Lektion geschafft.

Frage 1 von 3

Was ist der erste Schritt nach der Entdeckung?