WordPress-Sicherheit prüfen: die Liste mit Befehlen

11.334 neue Sicherheitslücken zählt Patchstack für 2025 im WordPress-Umfeld: 91 % in Plugins, 9 % in Themes, sechs im Kern. Bei 46 % gab es zum Zeitpunkt der Veröffentlichung noch keine Korrektur vom Entwickler. Wer nur auf das Kern-Update achtet, schaut auf den kleinsten Teil.

WordPress-Sicherheit heißt deshalb vor allem: nichts Veraltetes laufen lassen, keinem Konto mehr Rechte geben als nötig und eine Sicherung haben, die schon einmal zurückgespielt wurde. Firewall, Sicherheitsplugin und versteckte Anmeldeseite kommen danach und ersetzen keinen dieser Punkte. Dieser Beitrag ordnet die Maßnahmen nach Wirkung und sagt zu jeder, wie man sie prüft. Was zu tun ist, wenn es schon passiert ist, steht in WordPress gehackt: was tun.

Die Lage in Zahlen#

Die WordPress-Statistik auf wordpress.org zeigt, auf welchen Versionen die Installationen laufen, die sich bei WordPress.org melden. Stand 15. September 2026:

Knapp ein Drittel der gemeldeten Installationen läuft also nicht auf einer der beiden jüngsten Hauptversionen. Und fast zwei von fünf laufen auf einer PHP-Version, für die php.net keine Korrekturen mehr ausliefert: 8.1 endete am 31. Dezember 2025, 8.0 am 26. November 2023, 7.4 am 28. November 2022. WordPress selbst schreibt dazu auf der Seite mit den Anforderungen, solche Versionen „may expose your site to security vulnerabilities“.

Google nennt in der Hilfe für gehackte Websites vier Wege, auf denen Seiten übernommen werden: ein verseuchter Rechner des Administrators, schwache oder wiederverwendete Passwörter, veraltete Software und nachlässiger Code. Die Prüfliste folgt dieser Lage: zuerst das Veraltete, weil dort die Masse der Lücken liegt, dann die Zugänge, dann die Rechte, dann die Sicherung für den Fall, dass alles andere nicht gereicht hat.

Die Prüfliste, sortiert nach Wirkung#

Jeder Punkt hat einen Weg im Backend und, wo es ihn gibt, einen WP-CLI-Befehl. Die Befehle laufen im Verzeichnis der Installation auf dem Server.

1. Plugins und Themes: aktuell, gepflegt, oder weg#

Nachsehen lässt sich das unter „Plugins → Installierte Plugins“. Auf der Kommandozeile:

wp plugin list --update=available
wp plugin list --fields=name,status,version,update_version,auto_update
wp plugin list --fields=name,wporg_status,wporg_last_updated

Der erste Befehl listet nur Plugins mit verfügbarem Update, der zweite zeigt zusätzlich, ob automatische Updates an sind. Der dritte fragt den Stand im Verzeichnis auf wordpress.org ab; dort steht, ob ein Plugin geschlossen wurde. Auf der Plugin-Seite heißt das „This plugin has been closed and is no longer available for download“, und „Security Issue“ ist einer der fünf genannten Gründe. Die zweite Warnung, die zählt: „This plugin hasn't been tested with the latest 3 major releases of WordPress“.

Automatische Updates lassen sich seit WordPress 5.5 je Plugin in der Spalte „Automatische Aktualisierungen“ einschalten und je Theme im Detailfenster. WordPress prüft dann zweimal täglich und schickt eine E-Mail, wenn ein Update gelaufen oder gescheitert ist. Die Updates hängen an WP-Cron; ob der läuft, meldet „Werkzeuge → Website-Zustand“.

Was nicht gebraucht wird, gehört gelöscht. Die Hardening-Dokumentation sagt es ohne Einschränkung: „if you are not using a specific plugin, delete it from the system.“ Wie du ein Plugin schon vor der Installation prüfst, steht in WordPress-Plugins: welche, wie viele, und wie du sie prüfst. Inaktive Plugins zeigt wp plugin list --status=inactive. Plugins und Themes kommen laut derselben Dokumentation nur aus dem Verzeichnis auf WordPress.org oder von bekannten Anbietern. Dasselbe gilt für den Rechner, von dem aus die Seite verwaltet wird, denn ein verseuchter Admin-Rechner ist einer der vier Einfallswege von oben: Betriebssystem und Installationsmedien nur aus der Originalquelle, bei Windows also die ISO direkt von Microsoft (Anleitung zum Windows-11-ISO-Download).

Ob Dateien verändert wurden, vergleicht WP-CLI gegen die Prüfsummen von WordPress.org:

wp core verify-checksums
wp plugin verify-checksums --all

Der zweite Befehl kann nur Plugins prüfen, die im Verzeichnis auf WordPress.org stehen. Gekaufte Plugins fallen durch das Raster.

2. Der WordPress-Kern#

wp core version
wp core check-update
wp config get WP_AUTO_UPDATE_CORE

Wartungs- und Sicherheitsreleases spielt WordPress seit Version 3.7 selbst ein. Seit 5.6 aktualisieren sich neue Installationen auch bei Hauptversionen, außer WordPress findet eine Versionsverwaltung im Verzeichnis; bestehende Installationen behalten ihre Einstellung. Gesteuert wird das über WP_AUTO_UPDATE_CORE in der wp-config.php: 'minor' nimmt nur Wartungsreleases, true auch Hauptversionen, false schaltet ab. Fehlt die Konstante, gilt das Verhalten, das die Installation seit ihrer Einrichtung hat.

Ob der Mechanismus tatsächlich läuft, zeigt der Website-Zustand: „Hintergrund-Updates funktionieren nicht wie erwartet“ steht dort bei den kritischen Problemen. Wie viel davon abhängt, hat der Juli 2026 gezeigt: Für die Lücken aus Release 7.0.2 hat WordPress.org am 17. Juli erzwungene Updates über genau dieses System ausgerollt. Eine Seite, auf der es nicht lief, bekam sie nicht.

3. PHP#

Die laufende Version steht unter „Werkzeuge → Website-Zustand → Info → Server“. Ist sie veraltet, meldet der Reiter „Status“ das als kritisches Problem vom Typ „Security“. WordPress empfiehlt Hostern PHP 8.3 oder höher. Laut php.net bekommt 8.2 nur noch Sicherheitskorrekturen, und das bis zum 31. Dezember 2026; 8.3 bis Ende 2027. Umgestellt wird beim Hoster, nicht in WordPress.

4. Administratorkonten#

wp user list --role=administrator --fields=ID,user_login,user_registered

Jede Zeile muss einer Person gehören, die du kennst. Nur Administratoren dürfen auf einer Einzelseite Plugins installieren, Themes bearbeiten und Dateien ändern (install_plugins, edit_themes, edit_files); wer Beiträge schreibt, braucht die Rolle Redakteur oder Autor. Ein Benutzer, den niemand angelegt hat, führt die WordPress-Dokumentation als Anzeichen eines Angriffs: „creation of new users“. Und kein Benutzer sollte admin heißen; die Dokumentation zu Brute-Force-Angriffen: „Do not use the username admin. Create a separate admin account and demote or remove legacy users.“

5. Zwei-Faktor und Passwörter#

Für jedes Konto aus Punkt 4 muss ein zweiter Faktor eingerichtet sein. WordPress bringt ihn nicht mit („WordPress core does not ship 2FA“, heißt es in der Brute-Force-Dokumentation); er muss per Plugin oder über einen Identitätsanbieter kommen. Dieselbe Seite empfiehlt 2FA für alle Administratoren und nennt Passkeys (WebAuthn) als phishingresistente Alternative, mit mindestens zwei registrierten Geräten je Administrator.

Für die Passwörter gilt das BSI-Maß: 8 bis 12 Zeichen aus vier Zeichenarten, oder 20 bis 25 Zeichen aus zwei Zeichenarten, verwaltet in einem Passwortmanager, keines doppelt. Das gilt laut WordPress-Dokumentation für jeden Zugang: FTP oder SFTP, wp-admin, das Kundenmenü des Hosters und die Datenbank.

Anmeldeversuche gehören begrenzt, laut Brute-Force-Dokumentation „at the edge (WAF/CDN) or the web server“, also beim Hoster oder CDN, bevor die Anfrage WordPress erreicht. Erst wenn es das nicht gibt: „a security plugin can throttle login attempts.“

6. Anwendungspasswörter#

wp user application-password list 1

Anwendungspasswörter gibt es seit WordPress 5.6. Sie authentifizieren Programme gegenüber REST-API und XML-RPC, taugen aber nicht für die Anmeldung über wp-login.php. Im Profil stehen Erstellungsdatum und letzte Nutzung, und jedes lässt sich einzeln widerrufen, ohne das Passwort des Kontos zu ändern. Ein Eintrag, dessen Anwendung niemand mehr kennt, wird gelöscht. Wer die Funktion gar nicht braucht, schaltet sie ab:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

7. XML-RPC#

Zuerst ist zu klären, ob überhaupt etwas auf der Seite XML-RPC braucht; die Brute-Force-Dokumentation nennt Jetpack und mobile Apps als Beispiele. Sie beschreibt xmlrpc.php als „a frequent brute‑force target (especially the system.multicall method)“ und rät: „If you don't use XML‑RPC, disable it. If you do (e.g., Jetpack, mobile apps), restrict it (WAF rules) and rate‑limit aggressively.“

Der Filter reicht nicht ganz. Die Zeile

add_filter( 'xmlrpc_enabled', '__return_false' );

schaltet laut Referenz nur die Methoden ab, die eine Anmeldung verlangen. Pingbacks und Endpunkte ohne Anmeldung bleiben. Wer die Datei ganz sperren will, setzt dieselbe Serverregel, die die Hardening-Dokumentation für die wp-config.php zeigt, auf xmlrpc.php, auf Apache als <Files "xmlrpc.php"> mit Require all denied. Das ist eine Übertragung, keine eigene Empfehlung der Dokumentation, und sie gilt nur, wenn wirklich nichts XML-RPC braucht.

8. Dateieditor und Dateirechte#

wp config get DISALLOW_FILE_EDIT
ls -l wp-config.php

Fehlt die Konstante, lässt sich der Code von Themes und Plugins über den eingebauten Editor direkt im Backend ändern. Eine Zeile in der wp-config.php entzieht laut Hardening-Dokumentation allen Benutzern die Fähigkeiten edit_themes, edit_plugins und edit_files:

define( 'DISALLOW_FILE_EDIT', true );

DISALLOW_FILE_MODS geht weiter und sperrt auch Installation und Aktualisierung von Plugins und Themes im Backend; damit ist auch der Weg aus Punkt 1 zu, sinnvoll nur, wenn Updates anders laufen. FORCE_SSL_ADMIN sorgt dafür, dass Passwörter und Cookies für Anmeldung und Backend nie unverschlüsselt übertragen werden.

Dateirechte laut Hardening-Dokumentation: Verzeichnisse 755, Dateien 644, alles gehört dem eigenen Benutzerkonto. Schreibbar für den Webserver muss nur /wp-content/ sein. Die Befehle aus der Dokumentation:

find /pfad/zu/wordpress/ -type d -exec chmod 755 {} \;
find /pfad/zu/wordpress/ -type f -exec chmod 644 {} \;

Für die wp-config.php nennt sie 400 oder 440 und zusätzlich eine Sperre im Webserver:

<Files "wp-config.php">
Require all denied
</Files>

Ein Aufruf liefert dann ein HTTP 403, und das ist hier der gewollte Fall. Wo diese Regel neben dem Block von WordPress hingehört, steht in Die Standard-.htaccess von WordPress. Ob WordPress mit den Rechten noch arbeiten kann, zeigt der Website-Zustand unter „Dateisystem-Berechtigungen“.

9. Eine Sicherung, die zurückgespielt wurde#

Die Probe besteht darin, eine Sicherung zurückzuspielen, auf einer Testumgebung, nicht auf der Live-Seite, und nachzusehen, ob die Seite danach vollständig läuft.

Eine WordPress-Sicherung besteht laut Dokumentation aus Datenbank und Dateien; man braucht beide. Sie empfiehlt drei bis fünf aktuelle Stände an verschiedenen Orten und als Rhythmus wöchentlich für kleine Seiten, täglich für Seiten mit viel Bewegung. Automatische Sicherungen sollen ab und zu durch eine manuelle ergänzt werden, „to guarantee that the process is working“.

Das BSI geht weiter. Im IT-Grundschutz-Kompendium ist es eine Basis-Anforderung (CON.3.A15): Es muss regelmäßig getestet werden, „ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können“. Dieselbe Bausteinbeschreibung verlangt, Sicherungen vor unbefugtem Zugriff und vor dem Überschreiben zu schützen (CON.3.A14). Eine Sicherung, die auf demselben Server liegt und mit demselben Zugang überschrieben werden kann, erfüllt das nicht.

Die Maßnahmen im Überblick#

Von außen prüfen, ohne Serverzugang#

Was die Seite nach außen preisgibt, sieht man als angemeldeter Betreiber nicht. Die folgenden Befehle gehören an die eigene Domain.

# Server-Software und PHP-Version in den Kopfzeilen
curl -sI https://deine-domain.de/ | grep -iE '^(server|x-powered-by):'

# WordPress-Version im Generator-Tag
curl -s https://deine-domain.de/ | grep -i 'name="generator"'

# Antwortet XML-RPC?
curl -s https://deine-domain.de/xmlrpc.php

# Welche Benutzer zeigt die REST-API ohne Anmeldung?
curl -s https://deine-domain.de/wp-json/wp/v2/users

Die Kopfzeile X-Powered-By kommt von PHP selbst: Die Einstellung expose_php steht laut php.net standardmäßig auf 1 und schreibt die PHP-Version in jede Antwort. Das Generator-Tag erzeugt die Funktion wp_generator() im Kopf jeder Seite, mit der WordPress-Version. Die Datei xmlrpc.php antwortet auf eine GET-Anfrage mit Status 405 und dem Satz „XML-RPC server accepts POST requests only.“; nach einer Sperre wie in Punkt 7 kommt ein 403.

Der Benutzer-Endpunkt der REST-API liefert ohne Anmeldung laut Referenz name, slug, description, url und avatar_urls, beschränkt auf Benutzer mit veröffentlichten Beiträgen. Die REST-API abzuschalten, rät WordPress ab: „You should not disable the REST API; doing so will break WordPress Admin functionality“. Wer den Zugriff ohne Anmeldung einschränken will, nutzt laut derselben Seite den Filter rest_authentication_errors. Entspricht ein slug in der Liste deinem Anmeldenamen, ist die Hälfte der Zugangsdaten öffentlich, und Punkt 5 wird umso wichtiger.

Google prüft mit. Google Search Central empfiehlt zur Vorbeugung die Suche mit site:deine-domain.de und den Bericht „Sicherheitsprobleme“ in der Search Console. Seiten, die du nie angelegt hast, sind dort der deutlichste Befund; was dann zu tun ist, steht in WordPress gehackt: was tun.

Der Security-Scan ruft die Seite als Fremder ab und prüft passiv: HTTPS und Security-Header, ob Server oder X-Powered-By Software preisgeben, TLS-Version und Zertifikat, SPF und DMARC im DNS, offen liegende Dateien wie /.git/config, /.env und /backup.sql, Verzeichnisauflistungen, PHP-Fehlermeldungen im HTML, eingebundene fremde Skripte und ob Dienste wie FTP, MySQL oder Redis öffentlich antworten. Er prüft keine WordPress-Version und keine Plugins. Dafür sind die Befehle aus der Prüfliste da. Was die einzelnen Kopfzeilen bewirken, steht in Security-Header einrichten.

Von außen gesehen: 22 WordPress-Seiten aus Tirol#

In eigener Sache eine Zählung, nur lesend: Am 03.10.2026 habe ich 140 Tiroler Domains aus meiner Akquise-Liste (Betriebe und Tourismusverbände) einmal per curl abgerufen; 131 antworteten, 22 davon laden erkennbar wp-content. Nur Summen, keine Namen, und keine Abfrage von xmlrpc.php oder der REST-API, denn die Befehle oben gehören an die eigene Domain.

Bei fünf der sechs Header liegen die WordPress-Seiten unter dem Schnitt aller 131, nur bei der Permissions-Policy darüber. Das liegt nicht an WordPress, sondern daran, dass die Header beim Hoster oder in der .htaccess gesetzt werden und dort niemand hinsieht, solange das Backend grün ist. Die Hälfte der WordPress-Seiten zeigt ihre Version jedem, der den Quelltext öffnet; drei davon liegen mindestens eine Hauptversion hinter 7.1. Und die PHP-Zeile gilt für alle Systeme: 17 Server schreiben ihre PHP-Version in jede Antwort, sechs davon eine, für die php.net keine Korrekturen mehr ausliefert. Das ist die Statistik von oben, vor der Haustür.

Vier Reflexe, die nichts schließen#

Die Versionsnummer zu verstecken, statt zu aktualisieren, ändert nichts an der Lücke. remove_action( 'wp_head', 'wp_generator' ); entfernt das Generator-Tag; die Hardening-Dokumentation ordnet das unter „Security through obscurity“ ein und nennt es „generally an unsound primary strategy“. Dasselbe gilt für die umbenannte Anmeldeseite: „Obscuring the login URL can reduce noise but should not be your only defense.“ xmlrpc.php und die REST-API bleiben ohnehin, wo sie sind.

Ein Sicherheitsplugin statt Updates. Die Hardening-Dokumentation stellt Updates an den Anfang: „Older versions of WordPress are not maintained with security updates.“ Ein Plugin kann Anmeldeversuche drosseln und Dateien vergleichen; das anfällige Plugin daneben macht es nicht aktuell. Und bei 46 % der Lücken des Jahres 2025 gab es laut Patchstack zur Veröffentlichung noch kein Update. Dann hilft nur Deaktivieren und Löschen, kein Scanner.

Deaktivieren statt löschen. Ein deaktiviertes Plugin liegt mit allen Dateien weiter auf dem Server. Die Hardening-Dokumentation sagt löschen, und OWASP setzt „Remove unused dependencies, unnecessary features, components, files, and documentation“ an die erste Stelle der Gegenmaßnahmen gegen veraltete Komponenten.

Alle Rechte für alle. 777 behebt einen Update-Fehler und ist das Gegenteil dessen, was die Dokumentation beschreibt: Dateien, die „writable by only the user“ sind. Verlangt ein Update mehr als das, ist zuerst mit dem Hoster zu klären, wem die Dateien gehören.

Die Prüfliste ist unspektakulär, und genau deshalb bleibt sie liegen. Ein Sicherheitsplugin ist schnell installiert und zeigt ein grünes Dashboard; die Plugin-Liste gegen das Verzeichnis zu halten, PHP beim Hoster umzustellen und eine Sicherung probeweise zurückzuspielen, ist Arbeit ohne sichtbares Ergebnis. Die Zahlen oben sagen, wo das Risiko liegt: in Erweiterungen, die niemand aktualisiert, und auf PHP-Versionen, die niemand mehr pflegt. Beides findet ein Befehl, und beides behebt kein Plugin. Wer die Liste nicht jeden Monat selbst abarbeiten will, gibt sie ab; was die WordPress-Wartung davon erledigt und was nicht, steht auf der Leistungsseite. Wer ganz ohne Plugin-Pflege auskommen will, findet im Vergleich statische Seite, WordPress und Web-App, wann sich ein Umzug lohnt und wann nicht. Wenn die site:-Suche oder die Benutzerliste etwas zeigt, das nicht dorthin gehört, zuerst prüfen, ob die Seite gehackt ist, dann die neun Schritte in WordPress gehackt: was tun, in dieser Reihenfolge, weil Aufräumen ohne geänderte Zugänge den Angreifer drin lässt.

Häufige Fragen#

Stand 08.10.2026. Quellen am 03.10.2026 abgerufen; die Versionsstatistik von wordpress.org stammt vom 15.09.2026, die Zählung der 131 Tiroler Startseiten vom 03.10.2026, der Security-Scan vom 08.10.2026.