Zum Inhalt springen

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

Lupe neben einem zugeklappten Laptop auf einer hellen Arbeitsfläche
Ein Scan liest Versionsnummern. Die Befunde, die einen Befall möglich machen, liegen hinter dem Zugang.

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.

Was von außen sichtbar ist und was erst mit Zugang
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.

  1. 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“.
  2. 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.
  3. 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.
  4. 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.

Wo Schwachstellen herkommen und wer sie findet
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_options und 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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 Arbeitsweise

Weiterlesen

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.

theis@devslab.de +49 174 7284457 WhatsApp: schnelle Nachricht

Anliegen Sicherheitscheck