WordPress-Sicherheit prüfen: Schwachstellen selbst finden
Die Frage „ist meine WordPress-Seite sicher“ lässt sich nicht mit ja oder nein beantworten, aber in neun Prüfungen ziemlich genau beschreiben. Vier davon schaffst du in zwanzig Minuten ohne Werkzeuge, fünf brauchen Dateizugang. Was dabei nicht auffällt, steht am Ende, denn das ist der ehrlichere Teil der Antwort.
Von Dennis Theis 9 Min. Lesezeit
Wie prüfe ich die WordPress-Sicherheit?
Eine WordPress-Sicherheitsprüfung besteht aus drei Ebenen: dem Stand der Software, den Zugängen und der Konfiguration unterhalb von WordPress. Die erste Ebene prüft jeder Scanner, die zweite kannst du selbst im Dashboard nachsehen, die dritte braucht Zugriff auf Dateien und Datenbank. Angriffe nutzen fast immer die erste oder zweite Ebene, gefunden werden sie aber meist erst auf der dritten.
Das ist der Grund, warum eine Seite als „sauber gescannt“ gelten und trotzdem eine Backdoor tragen kann. Ein Scan vergleicht Versionsnummern mit einer Liste bekannter Lücken. Eine Datei, die ein Angreifer nachträglich in ein Upload-Verzeichnis gelegt hat, steht in keiner Liste.
| Scan von außen findet | Prüfung mit Zugang findet zusätzlich |
|---|---|
| WordPress-Version im Quelltext | veränderte Core-Dateien über den Prüfsummenabgleich |
| Plugin-Versionen gegen CVE-Listen | PHP-Dateien in wp-content/uploads |
| TLS-Konfiguration und Zertifikat | Administratorkonten, die niemand mehr zuordnen kann |
| fehlende Security-Header | Must-Use-Plugins und geplante Cron-Aufgaben |
| offen erreichbare Standardpfade | Rechte, die zu weit gehen |
| Einträge auf Blacklists | Backup-Lage und getestete Wiederherstellung |
| Dauer: zwei Minuten, Kosten: keine | Dauer: ein bis zwei Werktage, vier Punkte davon gehen ohne Werkzeug |
Vier Prüfungen ohne Werkzeuge
Diese vier gehen im Dashboard und im Dateimanager des Hosters. Zusammen decken sie die häufigsten Einfallstore ab.
- Aktualität: Unter Dashboard, Aktualisierungen stehen Core, Plugins und Themes. Interessant ist nicht nur, was veraltet ist, sondern auch, was verwaist ist: ein Plugin, dessen letztes Update zwei Jahre zurückliegt, bekommt keinen Patch mehr, wenn eine Lücke gemeldet wird. Das Datum steht im Plugin-Verzeichnis unter „Zuletzt aktualisiert“.
- Administratorkonten: Unter Benutzer nach Rolle „Administrator“ filtern. Jedes Konto muss einer Person zuzuordnen sein, die den Zugang heute noch braucht. Konten früherer Dienstleister, Testkonten und der Zugang eines Praktikanten von 2021 gehören gelöscht, nicht deaktiviert.
- Backup: Die entscheidende Frage ist nicht, ob Backups laufen, sondern wann zuletzt eine Wiederherstellung getestet wurde. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme. Prüf außerdem, ob es getrennt von der Website liegt: ein Archiv auf demselben Webspace ist bei einem Befall genauso betroffen.
- Upload-Verzeichnis: Öffne
wp-content/uploads/im Dateimanager und sortier nach Dateityp. Dort gehören Bilder, PDF und Videos hin. Eine.php-Datei zwischen den Jahresordnern ist kein Grenzfall, sondern ein Befund.
Wenn du dabei nichts findest, ist das eine gute Nachricht mit begrenzter Reichweite: du hast geprüft, was sichtbar ist. Zum Abhaken gibt es die WordPress-Sicherheits-Checkliste mit 21 Punkten in fünf Bereichen.
Fünf Prüfungen mit Dateizugang
Ab hier brauchst du SFTP oder SSH. Mit SSH und WP-CLI sind es jeweils einzelne Befehle.
1. Dateiintegrität des Core
WordPress bringt für jede Version Prüfsummen mit. Der Abgleich zeigt jede veränderte Core-Datei:
wp core verify-checksums
Meldet der Befehl Abweichungen in wp-admin oder wp-includes, ist das
ein ernster Befund. Legitime Plugins verändern keine Core-Dateien.
2. Must-Use-Plugins
Der Ordner wp-content/mu-plugins/ lädt automatisch, und was dort liegt, erscheint
in der normalen Plugin-Liste nicht. Manche Hoster legen dort selbst etwas ab, das ist
üblich. Alles andere gehört geprüft:
ls -la wp-content/mu-plugins/
wp plugin list --status=must-use 3. Geplante Aufgaben
Eingeschleuster Code hängt sich gern an WP-Cron, um sich nach einer Bereinigung selbst wiederherzustellen. Verdächtig sind Aufgaben, deren Name keinem installierten Plugin zuzuordnen ist:
wp cron event list 4. PHP-Ausführung in Uploads
Dass dort keine PHP-Datei liegt, ist die eine Hälfte. Die andere ist, ob der Server eine
ausführen würde. Das lässt sich gefahrlos testen: leg eine Datei
uploads/test.php mit dem Inhalt <?php echo 'ausfuehrbar'; ?>
an und ruf sie im Browser auf. Erscheint das Wort, fehlt die Sperre. Erscheint der Quelltext
oder ein 403, ist alles in Ordnung. Datei danach wieder löschen.
5. PHP-Version und Header
Eine PHP-Version ohne Sicherheitsupdates ist eine offene Tür unterhalb von WordPress. Den Supportstatus führt php.net. Die Security-Header siehst du von außen:
curl -sI https://deine-domain.de | grep -i "strict-transport\|content-security\|x-content-type\|referrer-policy" Sicherheitslücken finden: was Datenbanken leisten
Bekannte Lücken findest du über den Abgleich deines Plugin-Inventars gegen eine Schwachstellendatenbank. Das leisten Patchstack und WPScan kostenlos im Browser: Plugin-Name eingeben, installierte Version vergleichen.
Diese Datenbanken sind gut in dem, was sie abdecken, und ihre Grenze ist strukturell. Nach dem Patchstack-Bericht entfielen von den 11.334 Schwachstellen, die 2025 im WordPress-Ökosystem neu gemeldet wurden, 91 Prozent auf Plugins und 9 Prozent auf Themes. Im Core waren es sechs, alle mit niedriger Priorität. Gleichzeitig war fast die Hälfte dieser Lücken zum Zeitpunkt der Veröffentlichung noch ungepatcht. Ein Abgleich sagt dir also, ob ein Update bereitsteht, nicht ob du sicher bist.
| Art der Lücke | Beispiel | Findet sie |
|---|---|---|
| bekannte Plugin-Lücke | veraltete Version mit CVE-Eintrag | jeder Scanner |
| verwaistes Plugin | seit zwei Jahren ohne Update | Blick ins Verzeichnis |
| zu weite Rechte | Redakteur mit Administratorrolle | nur eine Prüfung von Hand |
| Konfiguration | PHP in Uploads erlaubt, Debug aktiv | nur mit Dateizugang |
| bereits eingeschleuster Code | Backdoor in mu-plugins | Prüfsumme und Dateisuche |
Was ein Sicherheitstest nicht sieht
Kostenlose Online-Checks prüfen die Außenhaut: TLS, Header, die im Quelltext sichtbare WordPress-Version, manchmal die Plugin-Liste. Das ist nützlich und in zwei Minuten erledigt. Vier Dinge sind von außen grundsätzlich nicht feststellbar, und es sind dieselben vier, die im bezahlten Check regelmäßig die kritischen Befunde stellen:
- ob Core-Dateien verändert wurden
- wie viele Administratorkonten existieren und wer dahintersteht
- was in
wp_optionsund in den Cron-Einträgen steht - ob ein Backup existiert, das sich wiederherstellen lässt
Dazu kommt eine zeitliche Grenze: ein Test beschreibt einen Zustand. Nach dem nächsten Plugin-Update ist es ein anderer. Zwischen zwei Prüfungen zählt deshalb nicht das Testen, sondern das Überwachen, also Updates, Dateiintegrität und Verfügbarkeit im Blick zu haben. Genau das ist der Inhalt eines Wartungspakets, und der Grund, warum eine einmalige Prüfung und laufende Wartung zwei verschiedene Dinge sind.
Lücken schließen: die Reihenfolge
Wenn du Befunde hast, arbeite sie nicht alphabetisch ab, sondern nach Wirkung. Die Reihenfolge, die sich in der Praxis bewährt hat:
- Zugänge zuerst. Unbekannte Administratorkonten löschen, Passwörter der verbliebenen erneuern, Zwei-Faktor-Anmeldung einschalten. Das kostet nichts und schließt das größte Tor.
- Dann die bekannten Lücken. Updates einspielen, verwaiste Plugins ersetzen oder entfernen. Vorher ein Backup, und bei mehreren Installationen nicht direkt auf der Live-Seite, sondern gestuft ausrollen.
- Dann die Konfiguration. PHP-Ausführung in Uploads sperren, Debug-Ausgaben abschalten, Security-Header setzen, Security Salts erneuern. Letzteres wirft alle bestehenden Sitzungen aus, auch die eines Angreifers.
- Zuletzt die Vorsorge. Backups mit getesteter Wiederherstellung, Dateiintegritätsprüfung, Verfügbarkeitsüberwachung.
Ein Sonderfall: Findest du eingeschleusten Code, drehst du die Reihenfolge. Dann geht es nicht mehr um Absichern, sondern um Bereinigen, und zwar vollständig, bevor du irgendetwas anderes tust. Wird eine Backdoor übersehen, ist die Seite nach Stunden wieder befallen.
Wann du prüfen lassen solltest
Selbst prüfen lohnt immer, es kostet einen Vormittag und deckt die häufigsten Fälle ab. Vier Situationen sprechen dafür, jemanden mit Zugang draufsehen zu lassen:
- Übernahme einer fremden Installation. Du weißt nicht, wer bisher Zugang hatte und was eingebaut wurde. Eine Bestandsaufnahme vor der ersten Rechnung schützt beide Seiten.
- Vor einem Relaunch oder einer Anbindung. Bevor ein Fachsystem an die Website angeschlossen wird, sollte klar sein, wer auf sie zugreifen kann.
- Nach einem Vorfall im Umfeld. Der Hoster meldet auffälligen Datenverkehr, eine Partnerseite wurde befallen, ein Mitarbeiter ist gegangen.
- Wenn du einen Nachweis brauchst. Nach Art. 24 DSGVO muss der Betreiber belegen können, dass er angemessene Maßnahmen getroffen hat. Ein schriftlicher Befund ist dieser Belege einer, eine Erinnerung ist es nicht.
Wie eine solche Prüfung abläuft, was in den acht Bereichen geprüft wird und was sie kostet, steht auf der Seite zum WordPress-Sicherheitscheck. Ist die Seite dagegen schon auffällig, also mit Warnung in Google, fremden Weiterleitungen oder einer Sperre durch den Hoster, führt der Weg nicht über eine Prüfung, sondern direkt über die Bereinigung.
Quellen
Dennis Theis
Freiberuflicher Webentwickler aus Berlin. Schwerpunkt sind Websites, die an die Systeme angebunden sind, in denen die Daten schon liegen.
Mehr über meine ArbeitsweiseWeiterlesen
- Die 5 häufigsten WordPress-Angriffsvektoren Wo Angreifer tatsächlich hereinkommen und was dagegen hilft.
- Kritische WordPress-Plugin-Lücken 2026 Fünf Erweiterungen mit CVSS 9.8 und höher, mit Fix-Versionen.
- WordPress-Schadcode finden und entfernen Die sechs Verstecke, und wie du prüfst, ob einer belegt ist.
Lieber einmal von außen prüfen lassen?
Ich übernehme Wartung, Updates und die Anbindung an deine Systeme. Schreib mir, was ansteht, und du bekommst eine Einschätzung, bevor irgendjemand ein Angebot schreibt.
Anfrage ist da.
Ich melde mich innerhalb eines Werktags. Schau sicherheitshalber auch in den Spam-Ordner.