WordPress sicher machen: Härtung, Erkennung und Notfallplan für bestehende Websites

Wer eine bestehende WordPress-Website betreibt, startet nicht auf der grünen Wiese. Die Installation läuft seit Jahren, irgendwann hat jemand ein Plugin für ein Kontaktformular installiert, eine Agentur hat einen Administratorzugang bekommen, und ob das nächtliche Backup jemals zurückgespielt wurde, weiß niemand genau. Genau in dieser Ausgangslage entscheidet sich, ob ein Angriff Erfolg hat.

WordPress sicher machen heißt deshalb: bekannte Einfallstore schließen, Zugänge und Rechte auf das Nötige reduzieren, die Installation technisch härten, Veränderungen sichtbar machen und einen geprüften Weg zurück haben. Diese Anleitung führt in dieser Reihenfolge durch die Maßnahmen, zeigt anschließend, woran sich eine Kompromittierung erkennen lässt, und beschreibt den Ablauf nach einem erfolgreichen Angriff.

Zuerst prüfen: Ist die Website womöglich schon kompromittiert?

Härten Sie keine Website, die bereits übernommen wurde. Passwortwechsel und neue Sicherheitsregeln warnen in diesem Fall nur den Angreifer, während vorhandene Hintertüren weiter funktionieren. Prüfen Sie deshalb vorab fünf Punkte:

1. Gibt es unter Benutzer Administratorkonten, die Sie nicht zuordnen können?
2. Liegen PHP-Dateien im Upload-Verzeichnis? Prüfbar per Konsole mit find wp-content/uploads -type f -name "*.php".
3. Wurden in den letzten Wochen PHP-Dateien verändert, ohne dass ein Update oder Deployment stattfand? find . -type f -name "*.php" -mtime -14 zeigt die Kandidaten.
4. Sind Plugins oder Themes installiert, die niemand aus dem Team kennt?
5. Meldet der Browser, der Hoster oder die Search Console Warnungen zu Ihrer Domain?

Trifft nichts davon zu, arbeiten Sie diese Anleitung von oben nach unten ab. Treffen zwei oder mehr Punkte zu, springen Sie zum Abschnitt Nach einem Hack und beginnen dort mit der Beweissicherung.

Zuständigkeit klären, bevor Sie anfangen

Viele Sicherheitslücken entstehen in der Lücke zwischen Hoster und Betreiber. Der Hoster verantwortet in der Regel Serverbetriebssystem, Webserver, PHP-Bereitstellung, Netzwerkfilter und die Absicherung des Kundenkontos. Alles innerhalb der Installation bleibt beim Betreiber: WordPress-Version, Plugins, Themes, Benutzerkonten, Rechte, Inhalte und die inhaltliche Prüfung der Backups.

Klären Sie deshalb vor der Härtung mit Ihrem Anbieter:

• Welche PHP-Version läuft, und wie lange erhält sie noch Sicherheitsupdates?
• Werden Backups serverseitig erstellt, wie lange werden sie aufbewahrt, und liegen sie außerhalb Ihres Webspace?
• Existiert eine vorgeschaltete Firewall, und welche Anfragen blockiert sie?
• Lässt sich die Ausführung von PHP im Upload-Verzeichnis serverseitig unterbinden?
• Ist für das Kundenkonto Mehrfaktor-Authentifizierung verfügbar?
• Liegen weitere Websites im selben Hosting-Paket, und sind deren Verzeichnisse voneinander getrennt?

Der letzte Punkt wird häufig unterschätzt. Teilen sich mehrere Installationen einen Webspace, genügt eine verwundbare Nebenseite, um alle Projekte zu erreichen.

Welche Maßnahme gegen welchen Angriffsweg wirkt

Sicherheitsmaßnahmen sind nicht austauschbar. Die folgende Übersicht ordnet die typischen Einfallstore den Gegenmaßnahmen zu und benennt, was gegen den jeweiligen Weg gerade nicht ausreicht.

Daraus ergibt sich die Bearbeitungsreihenfolge: erst Wiederherstellbarkeit, dann Versionsstand und Codemenge, dann Zugänge und Rechte, danach die technische Härtung und zum Schluss Überwachung und Notfallplan. Die offizielle WordPress-Dokumentation zur Härtung nennt als Grundlage dieselben Bausteine: aktuelle Software, vertrauenswürdige Quellen, starke Passwörter, geeignete Dateiberechtigungen und regelmäßige Backups.

Schritt 0: Ein Backup, das diesen Namen verdient

Bevor Sie an wp-config.php, Dateiberechtigungen oder Serverregeln arbeiten, brauchen Sie einen geprüften Rückweg. Ein vollständiges WordPress-Backup besteht laut der WordPress-Dokumentation zu Backups aus zwei Teilen, die beide vorhanden sein müssen:

• die Datenbank mit Beiträgen, Seiten, Optionen, Benutzern und Plugin-Daten
• die Dateien der Installation, insbesondere wp-content mit Uploads, Themes, Plugins sowie die Konfigurationsdateien

Ein Datenbankexport ohne Dateien stellt keine funktionierende Website her, ein Dateiarchiv ohne Datenbank ebenso wenig. Prüfen Sie Ihre Sicherungsstrategie anhand dieser Fragen:

• Liegt mindestens eine Kopie außerhalb des Webspace und außerhalb desselben Kundenkontos?
• Wie viele Wiederherstellungspunkte stehen zur Verfügung, und wie weit reichen sie zurück?
• Sind die Sicherungen verschlüsselt, und wer hat Zugriff darauf?
• Lässt sich ein einzelner Zeitpunkt gezielt auswählen?
• Wurde eine vollständige Wiederherstellung in einer getrennten Umgebung tatsächlich durchgeführt?

Die Aufbewahrungsdauer ist sicherheitsrelevant und wird oft zu kurz gewählt. Eine Kompromittierung fällt selten am selben Tag auf. Wer nur sieben Tage vorhält, hat bei einem vier Wochen alten Einbruch ausschließlich verseuchte Stände. Zwei bis drei Monate Rückgriff auf zumindest wöchentliche Sicherungen schaffen hier deutlich mehr Spielraum.

Ein Backup gilt erst als belastbar, wenn eine Wiederherstellung erfolgreich getestet wurde. Alles andere ist eine Vermutung über eine Datei.

Aktuelle Versionen als Sicherheitsmaßnahme

Veraltete Komponenten sind das häufigste Einfallstor. WordPress empfiehlt ausdrücklich, Core, Plugins und Themes auf unterstützten, aktuellen Versionen zu halten, da ältere Versionen keine Sicherheitsupdates mehr erhalten; die Vorgehensweise beschreibt die offizielle Anleitung zu Aktualisierungen.

Entscheidend ist das Zeitfenster: Sobald eine Sicherheitslücke behoben und veröffentlicht ist, lässt sich aus der Änderung ableiten, welcher Code verwundbar war. Automatisierte Scans suchen anschließend gezielt nach Installationen, die noch die alte Version ausliefern. Der Abstand zwischen Veröffentlichung und Einspielen ist damit das eigentliche Risiko, nicht die Lücke selbst.

Bringen Sie diese Bestandteile auf einen unterstützten Stand:

• WordPress Core
• alle aktiven Plugins
• das aktive Theme sowie ein gepflegtes Ersatz-Theme
• die eingesetzte PHP-Version
• serverseitige Komponenten des Hostings, soweit Sie sie verantworten

Gehen Sie dabei kontrolliert vor: Backup erstellen, Änderungsprotokolle auf Sicherheitshinweise und Inkompatibilitäten sichten, umfangreiche Sprünge zuerst in einer Testumgebung durchspielen, sicherheitsrelevante Aktualisierungen zeitnah einspielen und danach Login, Formulare, zentrale Seitentypen und Schnittstellen kontrollieren. Halten Sie fest, was wann aktualisiert wurde. Diese Notiz ist später bei der Ursachenanalyse Gold wert.

Automatische Updates verkürzen genau das kritische Zeitfenster und sind für Sicherheitsfreigaben des Core in den meisten Fällen die richtige Wahl. Bei Plugins hängt die Entscheidung von der Zuverlässigkeit des Anbieters und der Bedeutung der Website ab. Wo automatische Aktualisierungen aktiv sind, brauchen Sie eine funktionierende Fehlerbenachrichtigung, sonst bemerkt niemand einen fehlgeschlagenen Vorgang.

Ein aktives Plugin, das seit Jahren keine Aktualisierung erhalten hat, ist ein eigenes Risiko. Prüfen Sie in solchen Fällen, ob die Funktion noch benötigt wird oder durch eine gepflegte Alternative ersetzt werden kann.

Weniger installierter Code, weniger Angriffsfläche

Ein deaktiviertes Plugin liegt weiterhin auf dem Server, und sein Code kann unter Umständen direkt aufgerufen werden. Deaktivieren ist deshalb kein Ersatz für Löschen. Entfernen Sie konsequent:

• deaktivierte und dauerhaft ungenutzte Plugins
• ungenutzte Themes bis auf ein aktuelles Ersatz-Theme
• alte ZIP-Archive und Installationspakete im Webverzeichnis
• frühere Kopien der wp-config.php, etwa wp-config.php.bak oder wp-config.old
• Datenbankexporte im öffentlich erreichbaren Bereich
• stillgelegte Staging- oder Testinstallationen in Unterverzeichnissen
• Diagnoseskripte wie phpinfo.php
• nicht mehr benötigte Benutzerkonten und API-Zugänge

Achten Sie auf die Herkunft. WordPress nennt vertrauenswürdige Quellen ausdrücklich als Härtungsgrundlage. Kostenlos angebotene Kopien kommerzieller Themes und Plugins aus inoffiziellen Portalen enthalten regelmäßig absichtlich veränderten Code, der sich als reguläre Datei tarnt. Der Preisvorteil steht in keinem Verhältnis zum Aufwand einer späteren Bereinigung.

Zugänge absichern

Passwörter über alle beteiligten Dienste hinweg

Ein starkes WordPress-Passwort nützt wenig, wenn derselbe Zugang an anderer Stelle offen liegt. Vergeben Sie lange, zufällige und ausschließlich einmal verwendete Passwörter für:

• alle WordPress-Konten mit erweiterten Rechten
• das Hosting- und Kundenkonto
• SFTP- und SSH-Zugänge
• den Datenbankbenutzer
• das E-Mail-Postfach, über das Passwortwiederherstellungen laufen
• den Domain-Registrar und die DNS-Verwaltung
• CDN-, Firewall- und Backup-Dienste
• angebundene Analyse-, Shop- oder Automatisierungsdienste

Das E-Mail-Postfach verdient besondere Aufmerksamkeit. Wer es kontrolliert, kann in den meisten Systemen ein Passwort zurücksetzen und damit sämtliche darauf aufbauenden Schutzmaßnahmen umgehen.

Nutzen Sie einen Passwortmanager. Ein komplexes, aber wiederverwendetes Passwort ist bereits kompromittiert, sobald es in einem beliebigen fremden Datenleck auftaucht.

Mehrfaktor-Authentifizierung für alles Privilegierte

Mehrfaktor-Authentifizierung reduziert das Risiko, dass ein gestohlenes Passwort allein für eine Kontoübernahme ausreicht. Das OWASP-Merkblatt zur Mehrfaktor-Authentifizierung beschreibt sie als zentrale Schutzschicht gegen Angriffe mit erbeuteten Zugangsdaten.

Aktivieren Sie den zweiten Faktor nicht nur für den Hauptadministrator, sondern für jedes Konto mit erweiterten Rechten, und ebenso für Hosting, Registrar und Backup-Dienst. Bevorzugen Sie Authenticator-Apps, Sicherheitsschlüssel oder Passkeys gegenüber SMS. Hinterlegen Sie Wiederherstellungscodes an einem geschützten Ort außerhalb des Systems, das sie absichern.

Prüfen Sie zusätzlich den Wiederherstellungsweg: Wenn ein verlorenes zweites Gerät über eine einfache Rückfrage per E-Mail ersetzt werden kann, ist der Schutz nur so stark wie dieses Postfach.

Anmeldeversuche begrenzen

Automatisierte Angriffe probieren in kurzer Zeit große Mengen an Kombinationen durch. Eine geeignete Begrenzung erkennt auffällige Muster, sperrt zeitlich befristet und schließt legitime Benutzer nicht dauerhaft aus. Sinnvoll sind gestaffelte Wartezeiten bei wiederholten Fehlversuchen, eine zusätzliche Prüfung nach verdächtigem Verhalten, Benachrichtigungen bei Auffälligkeiten sowie die Protokollierung erfolgreicher und fehlgeschlagener Administratoranmeldungen.

Das bloße Verschieben der Login-Adresse ist keine Schutzmaßnahme, sondern eine Reduktion von Rauschen in den Logs. Weder schwache Passwörter noch verwundbare Plugins verschwinden dadurch.

Rollen nach dem Minimalprinzip

WordPress-Benutzerrollen definieren unterschiedliche Berechtigungen; Administratorrechte sollten deshalb nur Konten erhalten, die sie tatsächlich benötigen. Welche Fähigkeiten mit welcher Rolle verbunden sind, listet die Dokumentation zu Rollen und Berechtigungen.

Administratoren dürfen Plugins installieren, Einstellungen ändern und Benutzer verwalten. Ein übernommenes Administratorkonto entspricht damit einem vollständigen Zugriff auf die Website. Prüfen Sie regelmäßig:

• Welche Konten besitzen Administratorrechte, und ist jedes einer realen Person zugeordnet?
• Existieren noch Zugänge früherer Mitarbeiter, Agenturen oder Dienstleister?
• Werden Konten von mehreren Personen gemeinsam genutzt?
• Haben Redakteure Fähigkeiten, die ihre Aufgabe nicht erfordert?
• Ist die Selbstregistrierung aktiviert, und welche Standardrolle erhalten neue Konten?

Die letzten beiden Punkte lassen sich in den Einstellungen unter Mitgliedschaft und Standardrolle für neue Benutzer kontrollieren. Eine unbeabsichtigt offene Registrierung mit zu hoher Standardrolle ist ein stiller Dauerzugang.

Vergeben Sie ein eigenes Konto pro Person, damit Änderungen zuordenbar bleiben und einzelne Zugänge gezielt gesperrt werden können. Nutzen Sie für tägliche redaktionelle Arbeit kein Administratorkonto.

Application Passwords kontrollieren

WordPress Application Passwords sind für API-Zugriffe externer Anwendungen gedacht. Sie ersetzen nicht das reguläre Benutzerpasswort und lassen sich einzeln widerrufen, was sie deutlich besser kontrollierbar macht als die Weitergabe des Kontopassworts. Details beschreibt der Integrationsleitfaden zu Application Passwords.

Öffnen Sie die Profile aller privilegierten Konten und sehen Sie nach, welche Einträge dort bestehen. Widerrufen Sie jeden Zugang, dessen Zweck oder zugehörige Anwendung nicht mehr bekannt ist. Vergeben Sie bei neuen Einträgen sprechende Namen und dokumentieren Sie, welches System sie nutzt. Nach einem Sicherheitsvorfall gehören diese Passwörter ausnahmslos widerrufen.

HTTPS durchgängig erzwingen

HTTPS schützt die Übertragung von Anmeldedaten und anderen Informationen zwischen Browser und Webserver vor dem Mitlesen und Manipulieren auf dem Transportweg, wie das MDN-Glossar zu HTTPS beschreibt. Ohne durchgängige Verschlüsselung sind Passwörter und Sitzungscookies in fremden Netzen angreifbar.

Stellen Sie sicher, dass die gesamte Website über HTTPS erreichbar ist, HTTP-Anfragen zuverlässig umgeleitet werden, der Administrationsbereich ausschließlich verschlüsselt läuft, keine Formulare unverschlüsselt übertragen, keine Ressourcen über HTTP nachgeladen und die WordPress-Adressen in den Einstellungen korrekt gesetzt sind. Das Zertifikat sollte automatisch erneuert werden, und die Erneuerung braucht eine Überwachung.

Kontrollieren Sie zusätzlich die Strecke zwischen vorgeschaltetem Dienst und Ursprungsserver. Wenn ein CDN nach außen HTTPS anbietet, die Verbindung zum eigentlichen Webserver aber unverschlüsselt bleibt, verschiebt sich die Schwachstelle nur.

Technische Härtung der Installation

Datei-Editor im Backend deaktivieren

WordPress bringt einen Editor für Theme- und Plugin-Dateien mit. Erlangt jemand Administratorzugriff, wird daraus ein direkter Weg zur Codeausführung. Mit der Konstante DISALLOW_FILE_EDIT lässt sich dieser Editor deaktivieren, wie die Dokumentation zur wp-config.php beschreibt:

define( 'DISALLOW_FILE_EDIT', true );

Fügen Sie die Zeile vor dem abschließenden Hinweiskommentar der Konfigurationsdatei ein, sichern Sie die Datei vorher und rufen Sie die Website unmittelbar danach auf, um einen Syntaxfehler auszuschließen. Die Einstellung verhindert keine Änderungen über SFTP, SSH oder Deployment-Prozesse, entfernt aber einen unnötigen Weg aus dem Administrationsbereich.

Authentifizierungsschlüssel und Salts erneuern

WordPress verwendet Authentifizierungsschlüssel und Salts in der wp-config.php, um in Cookies gespeicherte Anmeldedaten kryptografisch abzusichern; die technische Einordnung liefert die Dokumentation zu Security Keys. Betroffen sind acht Konstanten:

AUTH_KEY
SECURE_AUTH_KEY
LOGGED_IN_KEY
NONCE_KEY
AUTH_SALT
SECURE_AUTH_SALT
LOGGED_IN_SALT
NONCE_SALT

Jede Installation braucht eigene, zufällig erzeugte Werte. Beispielwerte aus Anleitungen und über mehrere Projekte kopierte Schlüssel gehören ersetzt; WordPress stellt dafür unter https://api.wordpress.org/secret-key/1.1/salt/ einen Generator bereit. Werden die Werte ausgetauscht, verlieren alle bestehenden Sitzungen ihre Gültigkeit. Genau deshalb ist dieser Schritt nach einem vermuteten Kontodiebstahl Pflicht: Ein Angreifer mit gültigem Sitzungscookie bleibt sonst angemeldet, obwohl das Passwort längst geändert wurde.

Dateiberechtigungen restriktiv setzen

Dateien und Verzeichnisse dürfen nur für die Prozesse beschreibbar sein, die den Zugriff wirklich benötigen. Als Ausgangswerte gelten üblicherweise 755 für Verzeichnisse und 644 für Dateien, für die wp-config.php nach Möglichkeit restriktiver.

Diese Zahlen sind kein universeller Standard. Die passende Konfiguration hängt davon ab, unter welchem Benutzer PHP ausgeführt wird und wem die Dateien gehören. Bei verwaltetem Hosting fragen Sie die empfohlenen Werte beim Anbieter ab, statt zu raten. Setzen Sie nichts auf 777: Damit darf jeder Prozess auf dem System schreiben, und aus einer kleinen Schwachstelle wird ein vollständiger Zugriff.

Besonders sensibel sind wp-config.php, Serverkonfigurationen wie .htaccess, die Plugin- und Theme-Verzeichnisse, der Upload-Ordner sowie Backup-, Protokoll- und Cache-Verzeichnisse. Der Upload-Ordner muss Mediendateien aufnehmen, sollte aber niemals PHP ausführen. Ob sich das serverseitig unterbinden lässt, klären Sie mit Ihrem Hoster.

Sensible Dateien vor öffentlichem Zugriff schützen

Konfigurationsdateien, Protokolle und Sicherungen dürfen nicht über eine URL abrufbar sein. Testen Sie gezielt, ob sich Sicherungskopien der wp-config.php, Datenbankexporte, Debug- und Serverprotokolle, ZIP-Archive der Website, Verzeichnisse der Versionsverwaltung oder temporäre Dateien von Editoren aufrufen lassen.

Deaktivieren Sie zusätzlich die Auflistung von Verzeichnisinhalten. Die konkreten Regeln unterscheiden sich zwischen Apache, Nginx, LiteSpeed und verwalteten Plattformen erheblich, und eine fehlerhafte Regel kann die Website unerreichbar machen. Ändern Sie solche Konfigurationen nur mit Sicherung und anschließender Funktionsprüfung.

Debug-Ausgaben auf Produktivsystemen unterbinden

Fehlermeldungen legen Dateipfade, Datenbanknamen und Versionsstände offen und erleichtern damit die Orientierung im System. Auf einer öffentlich erreichbaren Website sollten PHP- und WordPress-Fehler nicht an Besucher ausgegeben werden. Ist eine Protokollierung für die Fehlersuche nötig, schreiben Sie sie in eine Datei außerhalb des öffentlichen Verzeichnisses.

Löschen Sie vorhandene Debug-Protokolle nicht vorschnell, wenn Sie einen Vorfall untersuchen. Sie enthalten oft die einzigen brauchbaren Zeitstempel.

REST API prüfen statt pauschal abschalten

Die WordPress REST API ist Bestandteil des Core und wird sowohl von WordPress-Funktionen als auch von externen Anwendungen genutzt; ein pauschales Deaktivieren kann benötigte Funktionen beeinträchtigen. Die offizielle REST-API-Dokumentation beschreibt sie als reguläre Schnittstelle, nicht als optionale Zusatzfunktion.

Statt sie abzuschalten, verschaffen Sie sich Klarheit über das, was sie ausgibt. Rufen Sie /wp-json/ und /wp-json/wp/v2/users in Ihrem Browser auf und sehen Sie nach, welche Endpunkte registriert sind und welche Informationen ohne Anmeldung sichtbar werden. Prüfen Sie anschließend, ob selbst entwickelte Endpunkte eine Berechtigungsprüfung besitzen, ob Plugins den Zugriff nur in der Oberfläche oder auch serverseitig begrenzen und ob vertrauliche Felder in Antworten auftauchen. Sicherheit entsteht hier durch korrekte Autorisierung, nicht durch das Abschalten einer zentralen Schnittstelle.

XML-RPC nach tatsächlichem Bedarf behandeln

Die Datei xmlrpc.php ermöglicht externe Zugriffe und wird von einigen Anwendungen und Diensten benötigt. Gleichzeitig eignet sie sich für automatisierte Anmeldeversuche. Klären Sie zuerst, ob eine angebundene App oder ein Dienst darauf angewiesen ist. Falls nicht, sperren oder begrenzen Sie den Zugriff serverseitig. Eine pauschale Sperre ohne Prüfung unterbricht sonst funktionierende Integrationen, deren Ausfall oft erst Wochen später auffällt.

Datenbankzugang absichern

Die Datenbank sollte nicht aus dem Internet erreichbar sein, sofern das nicht zwingend erforderlich ist. Verwenden Sie einen eigenen Datenbankbenutzer je Installation mit ausschließlich den benötigten Rechten, und nutzen Sie diese Zugangsdaten für keinen weiteren Dienst.

Ein individueller Tabellenpräfix erschwert einzelne automatisierte Angriffe geringfügig, ersetzt aber weder Aktualisierungen noch sichere Zugänge. Eine nachträgliche Umstellung an einer laufenden Website birgt zudem ein reales Risiko für Datenverlust und lohnt sich in den meisten Fällen nicht.

Sicherheits-Plugins und Firewalls richtig einordnen

Ein Sicherheits-Plugin bündelt typischerweise mehrere Aufgaben: Überwachung von Dateiänderungen, Vergleich der Core-Dateien mit den offiziellen Versionen, Erkennung bekannter Schadcode-Muster, Begrenzung von Anmeldeversuchen, Benachrichtigung bei neuen Administratoren und Protokollierung sicherheitsrelevanter Ereignisse. Der eigentliche Nutzen liegt in der Sichtbarkeit, nicht in der Abwehr.

Installieren Sie nicht mehrere umfangreiche Sicherheitspakete parallel. Überschneidende Funktionen behindern sich gegenseitig, erzeugen Fehlalarme und produzieren Protokollmengen, die niemand mehr liest.

Eine vorgeschaltete Web Application Firewall blockiert verdächtige Anfragen, bevor sie WordPress erreichen, und hilft besonders gegen breit gestreute automatisierte Angriffe. Sie beseitigt jedoch keine Schwachstelle im Code. Die betroffene Komponente muss trotzdem aktualisiert, ersetzt oder entfernt werden.

Eine Kompromittierung erkennen

Angreifer haben in der Regel kein Interesse daran, aufzufallen. Statt einer sichtbaren Verunstaltung finden sich meist versteckte Weiterleitungen, eingeschleuste Seiten oder ein stiller Dauerzugang.

Mögliche Anzeichen sind:

• unbekannte Administrator- oder Benutzerkonten
• Plugins oder Themes, die niemand installiert hat
• veränderte Core-, Plugin- oder Theme-Dateien
• PHP-Dateien im Upload-Verzeichnis
• Weiterleitungen auf fremde Domains, oft nur für Besucher aus Suchergebnissen
• unbekannte Seiten mit fremdsprachigen Inhalten
• verdächtige geplante Aufgaben
• unerklärliche Änderungen an der wp-config.php
• auffällige Einträge in Optionen oder Beitragsinhalten der Datenbank
• Sicherheitswarnungen von Hoster oder Browser
• unerwartete ausgehende E-Mails oder Beschwerden über Spam
• deutlich erhöhte Serverlast ohne erklärbaren Grund
• ungewöhnlich lange Ladezeiten ohne erkennbare technische Ursache
• Anmeldungen aus Regionen, in denen niemand aus dem Team arbeitet
• deaktivierte Sicherheits- oder Backup-Funktionen
• wiederkehrende Schaddateien nach einer vermeintlichen Bereinigung
• Sichtbarkeitsverluste in Suchmaschinen, sobald manipulierte Inhalte oder Weiterleitungen erkannt werden

Einzelne Auffälligkeiten haben oft harmlose Ursachen. Treten mehrere gleichzeitig auf, behandeln Sie den Fall als Sicherheitsvorfall.

Konkret nachsehen

Mit Konsolenzugriff lassen sich die wichtigsten Prüfungen in wenigen Minuten durchführen. Steht WP-CLI zur Verfügung, vergleichen wp core verify-checksums und wp plugin verify-checksums --all die installierten Dateien mit den offiziellen Versionen und melden Abweichungen. wp user list --role=administrator listet alle Konten mit vollen Rechten samt E-Mail-Adresse.

Ohne WP-CLI helfen die eingangs genannten find-Aufrufe: PHP-Dateien im Upload-Verzeichnis sind praktisch nie legitim, und kürzlich geänderte PHP-Dateien ohne zugehöriges Update sind ein belastbarer Hinweis. Kontrollieren Sie außerdem die Liste der geplanten Aufgaben, denn viele Hintertüren stellen sich über einen Cron-Eintrag selbst wieder her.

Eine Vergleichsbasis schaffen

Abweichungen erkennt nur, wer den Sollzustand kennt. Dokumentieren Sie deshalb im sauberen Zustand: installierte WordPress-Version, Liste der Plugins und Themes mit Versionsnummern, alle privilegierten Benutzer, aktive externe Integrationen und Application Passwords, geplante Aufgaben, relevante Server- und PHP-Einstellungen sowie die üblichen IP-Bereiche administrativer Zugriffe.

Richten Sie Benachrichtigungen für die kritischen Ereignisse ein: neue Administratoren, Änderungen an Dateien in sensiblen Verzeichnissen, gehäufte fehlgeschlagene Anmeldungen und deaktivierte Sicherheitsfunktionen. Eine Meldung, die niemand liest, ist keine Überwachung. Legen Sie fest, wer sie empfängt und wer bei Abwesenheit einspringt.

Nach einem Hack: der Ablauf

Unkoordinierte Reaktionen vernichten Spuren und übersehen Hintertüren. Arbeiten Sie diese Reihenfolge ab.

1. Zugriff kontrolliert begrenzen

Versetzen Sie die Website bei akuter Gefahr in einen Wartungszustand oder beschränken Sie den Zugriff serverseitig. Stimmen Sie das bei geschäftskritischen Systemen mit Hosting, IT-Verantwortlichen und der betreuenden Agentur ab. Trennen Sie nicht vorschnell sämtliche Systeme, bevor Protokolle gesichert sind. Bei laufendem Datenabfluss geht eine sofortige Isolation dennoch vor.

2. Beweise sichern

Erstellen Sie eine Kopie des kompromittierten Zustands: Dateien mit Zeitstempeln, Datenbank, Webserver- und Zugriffsprotokolle, PHP- und Anwendungsprotokolle, Firewall- und CDN-Ereignisse, WordPress-Aktivitätsprotokolle sowie die Liste der Benutzer und aktiven Sitzungen. Diese Sicherung ist ausdrücklich kein Wiederherstellungsbackup, sondern die Grundlage der Ursachenanalyse. Halten Sie sie getrennt von den sauberen Sicherungen.

3. Zugangsdaten von einem geprüften Gerät ändern

Rotieren Sie alle Zugangsdaten, die betroffen sein könnten: WordPress-Konten, Hosting, SFTP und SSH, Datenbank, Wiederherstellungspostfächer, Domain- und DNS-Verwaltung, CDN und Firewall, Backup-Dienste, API-Schlüssel und Application Passwords.

Führen Sie diese Änderungen ausschließlich von einem vertrauenswürdigen, überprüften Gerät aus. Enthält der eigene Rechner Schadsoftware, werden die neuen Passwörter unmittelbar wieder abgegriffen. Erneuern Sie zusätzlich Schlüssel und Salts in der wp-config.php, damit bestehende Sitzungen ungültig werden.

4. Ursache bestimmen

Eine Bereinigung ohne bekannte Ursache ist eine Verzögerung, keine Lösung. Prüfen Sie verwundbare Plugins und Themes, gestohlene Administratorzugänge, kompromittierte Hosting- oder SFTP-Konten, manipulierte lokale Geräte, unsichere Eigenentwicklungen, fremde Skripte und Integrationen, zu weitreichende Dateiberechtigungen, weitere Installationen im selben Hosting-Paket sowie ungeschützte Backups und Testumgebungen.

Liegen mehrere Websites im selben Konto, gehören alle untersucht. Schadcode wandert zuverlässig zwischen beschreibbaren Verzeichnissen.

5. Sauber neu aufbauen

Der verlässlichste Weg führt über einen Neuaufbau aus geprüften Quellen: getrennte, saubere Umgebung bereitstellen, WordPress Core aus der offiziellen Quelle neu installieren, benötigte Plugins und Themes aus vertrauenswürdigen Quellen frisch installieren, Konfiguration kontrolliert übertragen, Uploads auf ausführbare Dateien prüfen, Datenbank untersuchen und bereinigen und ausschließlich Inhalte übernehmen, deren Herkunft nachvollziehbar ist. Spielen Sie keine alten Programmdateien unbesehen zurück.

Das Löschen einer gefundenen Schaddatei genügt selten. Angreifer hinterlassen üblicherweise mehrere Hintertüren, und nach der Entfernung des sichtbarsten Symptoms taucht der Code kurz darauf erneut auf.

6. Backups nur nach Prüfung einspielen

Ein älteres Backup beschleunigt die Wiederherstellung, muss aber nachweislich vor der Kompromittierung entstanden sein. Der Zeitpunkt der Erstkompromittierung liegt oft deutlich vor dem Zeitpunkt der Entdeckung, weshalb die Protokolle aus Schritt 2 hier gebraucht werden. Prüfen Sie außerdem, ob der wiederhergestellte Stand die ausgenutzte Schwachstelle noch enthält. Anschließend gehören alle Sicherheitsupdates eingespielt und alle Zugangsdaten rotiert, sonst folgt der nächste Vorfall unmittelbar.

7. Auswirkungen und Meldepflichten prüfen

Klären Sie, ob personenbezogene Daten, Bestellungen, Formulareingaben oder Zugangsdaten betroffen sein könnten, und dokumentieren Sie Zeitpunkt, Umfang, betroffene Systeme und ergriffene Maßnahmen. Besprechen Sie mögliche Informations- und Meldepflichten mit der zuständigen Datenschutzverantwortung oder qualifizierter rechtlicher Beratung. Informieren Sie Hosting-Anbieter, Zahlungsdienstleister und weitere beteiligte Stellen, wenn deren Systeme oder Zugangsdaten betroffen sein könnten.

8. Kontrolliert wieder freigeben

Vor der erneuten Veröffentlichung sollten keine unbekannten Konten und keine verdächtigen Dateien oder Datenbankeinträge mehr vorhanden sein, alle Komponenten aus vertrauenswürdigen Quellen stammen und aktuell sein, sämtliche Zugangsdaten ausgetauscht und aktive Sitzungen beendet sein, Mehrfaktor-Authentifizierung eingerichtet, Dateiberechtigungen kontrolliert, Protokollierung und Überwachung aktiv, Formulare und Schnittstellen getestet, eine neue vollständige Sicherung erstellt und der Wiederherstellungsweg dokumentiert sein.

Beobachten Sie die Website danach mehrere Wochen besonders eng. Wiederkehrende Dateien oder neue Konten bedeuten, dass eine Hintertür oder der ursprüngliche Zugangsweg übersehen wurde.

Sicherheitsroutine im laufenden Betrieb

WordPress sicher zu machen ist kein einmaliger Vorgang. Legen Sie Verantwortlichkeiten und Intervalle schriftlich fest.

Täglich oder laufend: Erfolg der Backups kontrollieren, kritische Sicherheitsmeldungen sichten, Ausfälle und Dateiänderungen überwachen, Benachrichtigungen zu neuen Administratoren und auffälligen Anmeldungen auswerten.

Wöchentlich: sicherheitsrelevante Aktualisierungen prüfen und einspielen, fehlgeschlagene Anmeldungen auswerten, neue Benutzer kontrollieren, Firewall- und Sicherheitswarnungen durchgehen.

Monatlich: vollständige Liste der Plugins und Themes prüfen, nicht mehr benötigte Komponenten entfernen, Rollen und externe Zugänge kontrollieren, Application Passwords und API-Schlüssel abgleichen, die Wiederherstellbarkeit einer ausgewählten Sicherung testen.

Mehrmals jährlich: den Notfallablauf vollständig durchspielen, Administratorrechte neu bestätigen lassen, Hosting-, DNS- und Domain-Zugänge prüfen, den Supportstatus der eingesetzten PHP- und Softwareversionen kontrollieren, Ansprechpartner und Notfallkontakte aktualisieren, eine vollständige Wiederherstellung in einer getrennten Umgebung durchführen.

Halten Sie zu jeder Prüfung Datum, verantwortliche Person, festgestellte Abweichungen und ergriffene Maßnahmen fest.

Häufige Fehler beim Absichern von WordPress

Nur ein Sicherheits-Plugin installieren. Es erhöht die Sichtbarkeit, schützt aber nicht vor gestohlenen Hosting-Zugängen, veralteten Komponenten oder fehlenden Backups.

Backups im gleichen Webspace ablegen. Wer Zugriff auf den Webspace erlangt, erreicht dort abgelegte Sicherungen ebenfalls und kann sie löschen oder manipulieren.

Allen Beteiligten Administratorrechte geben. Jedes zusätzliche privilegierte Konto vergrößert die Angriffsfläche, ohne die Arbeit spürbar zu erleichtern.

Deaktivieren statt löschen. Ungenutzter Code bleibt auf dem Server angreifbar, auch wenn er im Backend inaktiv erscheint.

Eine gefundene Datei einfach entfernen. Ohne Ursachenanalyse bleibt die Website kompromittiert, und der Code kehrt zurück.

Die REST API pauschal abschalten. Das beschädigt Funktionen und Integrationen, ohne die eigentliche Schwachstelle zu beheben.

Auf eine versteckte Login-Adresse vertrauen. Sie reduziert Rauschen, ersetzt aber weder aktuelle Versionen noch sichere Zugänge.

Nach einem Hack nur das Backup einspielen. Ist die ausgenutzte Lücke weiterhin offen oder der Schadcode bereits enthalten, wiederholt sich der Vorfall.

Die ersten 30 Minuten

Wenn heute nur ein kurzes Zeitfenster zur Verfügung steht, arbeiten Sie diese Punkte in dieser Reihenfolge ab:

1. Vollständige Sicherung aus Dateien und Datenbank erstellen und außerhalb des Webspace ablegen.
2. Verfügbare Sicherheitsupdates für Core, Plugins und Themes einspielen.
3. Dauerhaft ungenutzte Plugins und Themes löschen, nicht nur deaktivieren.
4. Administratorenliste durchgehen und unbekannte oder nicht mehr benötigte Konten entfernen.
5. Passwörter aller privilegierten Konten neu vergeben.
6. Mehrfaktor-Authentifizierung für Administratoren und das Hosting-Konto aktivieren.
7. Prüfen, ob die gesamte Website über HTTPS erreichbar ist und HTTP zuverlässig umgeleitet wird.
8. DISALLOW_FILE_EDIT in der wp-config.php setzen.
9. Upload-Verzeichnis auf PHP-Dateien prüfen.
10. Mindestens eine Benachrichtigung für neue Administratoren und Änderungen an sensiblen Dateien einrichten.

Planen Sie danach einen längeren Termin für Serverkonfiguration, Dateiberechtigungen, Protokolle, Integrationen und einen echten Wiederherstellungstest.

Fazit: Schutzschichten, die einzeln überprüfbar sind

Die größte Wirkung erzielen Sie zuerst mit den Grundlagen: geprüfte Backups aus Datenbank und Dateien, unterstützte Versionen, wenig installierter Code aus vertrauenswürdigen Quellen, einzigartige Passwörter, Mehrfaktor-Authentifizierung und minimale Rechte. Diese Maßnahmen entziehen den meisten automatisierten Angriffen die Grundlage.

Darauf setzt die technische Härtung auf: durchgängiges HTTPS, restriktive Dateiberechtigungen, geschützte Konfigurationsdateien, ein deaktivierter Datei-Editor, eigene Schlüssel und Salts sowie ein bewusster Umgang mit Schnittstellen statt pauschaler Abschaltungen.

Den Unterschied macht am Ende die Vorbereitung auf den Ernstfall. Eine gut abgesicherte WordPress-Website ist nicht nur schwerer anzugreifen. Ihr Betreiber bemerkt verdächtige Veränderungen frühzeitig, kann einen Vorfall geordnet eindämmen, die Ursache benennen und das System aus einem nachweislich sauberen Zustand wieder aufbauen.