CMS ADMINS Security Check Report: Sicherheitscheck für WordPress

Änderungsprotokoll

Versionen vor 2.2.0 stehen in changelog.txt.

2.4.0

Neu

• Eine Checkliste statt eines einmaligen Urteils. Ab dem zweiten Durchlauf öffnet die Seite mit einer Übersicht: die Note, wo die Website angefangen hat und wo sie heute steht, ein Balken für jeden Durchlauf, die fünf Dinge zum Abarbeiten, was noch offen ist und was wann behoben wurde. Die geführte Abfolge aus drei Schritten bleibt für den ersten Durchlauf.
• Jede Aufgabe trägt einen Button, der genau diese eine Prüfung erneut ausführt und innerhalb von Sekunden antwortet. Eine Korrektur ist bestätigt, während du noch vor der Seite sitzt, und die nächste Aufgabe rückt nach, statt auf den nächsten vollständigen Durchgang zu warten.
• Ein Verlauf der letzten 24 Durchläufe. Der allererste bleibt dauerhaft erhalten, damit der einleitende Satz immer nennen kann, wo die Website angefangen hat. Eine Installation, die von einer früheren Version kommt, findet ihre zwei gespeicherten Durchläufe als die ersten beiden Punkte wieder.
• Fortschritt pro Kategorie, damit sichtbar ist, welcher Teil der Website erledigt ist und welcher nicht.
• Ein sechster Bereich, Transparenz und Offenlegung, mit einer Prüfung darin: ob KI-generierte Inhalte auf der Website gekennzeichnet sind. Artikel 50 des EU AI Act verlangt seit dem 2. August 2026 eine maschinenlesbare Kennzeichnung und einen Hinweis bei KI-Chatbots. Die Offenlegungs-Plugins aus dem Plugin-Verzeichnis werden an ihrem Ordner und an den Einstellungen erkannt, die sie schreiben, und die Prüfung warnt nur, weil eine Website ohne KI-Inhalte nichts zu kennzeichnen hat.
• Eine Zahl am Menüeintrag, ein Widget im Dashboard und eine Erinnerung, sobald der letzte vollständige Durchlauf älter als dreißig Tage ist. Die Erinnerung lässt sich dauerhaft abschalten, pro Benutzer.

Geändert

• Der Bericht wird jetzt auf dem Server gebaut. Früher wurde er im Browser zusammengesetzt, damit konnte es die Übersicht vor dem Ende eines Durchlaufs nicht geben, und dasselbe Markup hätte zweimal geschrieben werden müssen.
• Eine einzelne erneute Prüfung schreibt nie einen Punkt in den Verlauf, und die Seite sagt deutlich, dass die Note dann zum Teil auf älteren Messungen beruht. Ein Teildurchgang ist kein Durchlauf.
• Ein Durchlauf speichert, was jede Prüfung gemeldet hat, damit sich der Bericht neu aufbauen lässt, ohne alles erneut auszuführen.

Behoben

Jede Prüfung wurde gegen die Quellen gelesen, die sie nennt: php.net, das WordPress-Handbuch, den Core-Quelltext, MDN und die Pakete der Plugins, die sie erkennt. Dabei kamen Befunde heraus, die bei korrekter Konfiguration auslösen, einer, der überhaupt nicht auslösen konnte, und Aussagen, die seit Jahren nicht mehr stimmen.

• Websites mit Zwei-Faktor-Schutz wurden gemeldet, als hätten sie keinen. Der für iThemes, Solid und Kadence Security hinterlegte Benutzer-Meta-Schlüssel ist nicht der, den diese Plugins schreiben, und den für Defender gibt es dort überhaupt nicht. Google Authenticator speichert die Zeichenkette „disabled“, die als zweiter Faktor zählte, weil sie nicht leer ist. Damit blieb genau der Fall unbemerkt, für den es die Prüfung gibt.
• Die Prüfung auf Plugins, die aus dem Verzeichnis entfernt wurden, konnte gar nicht auslösen. Die API antwortet bei einem geschlossenen Eintrag mit 404, und die WordPress-Funktion macht daraus einen Fehler, bevor das Kennzeichen „closed“ überhaupt gelesen wird. Die Prüfung gab also genau in dem Fall Entwarnung, für den sie geschrieben wurde. Sie fragt den Endpunkt jetzt selbst ab und unterscheidet einen geschlossenen Eintrag, ein nie gelistetes Plugin und ein nicht erreichbares.
• Ein WordPress, das in einem eigenen Verzeichnis installiert ist, wurde als eingeschleuster Optionswert gemeldet, mit kritischer Dringlichkeit. Der Vergleich von WordPress-Adresse und Website-Adresse kann das nicht von einer Übernahme unterscheiden, und bei einer echten Übernahme werden beide gemeinsam geändert. Der Vergleich ist deshalb entfallen.
• Eine Website hinter Cloudflare wurde gemeldet, als ließe sich ihre Client-Adresse fälschen. Die Prüfung sucht jetzt nach einem Proxy, der sich zu erkennen gibt, und meldet das Ergebnis als nicht ermittelt, wenn sie es nicht entscheiden kann, statt zu warnen.
• Die WooCommerce Store API wurde als ungeschützte Schreibroute gemeldet. Eine Route als öffentlich zu registrieren ist die Schreibweise, die das Handbuch vorgibt, deshalb werden eine Route ganz ohne Permission-Callback und eine absichtlich öffentliche jetzt auseinandergehalten.
• Die strenge Content Security Policy aus der veröffentlichten Empfehlung wurde gemeldet, als ließe sie genau die Lücke offen, die sie schließt. Browser, die ’strict-dynamic‘ verstehen, ignorieren den daneben stehenden Fallback ‚unsafe-inline‘, und die Prüfung macht das jetzt ebenso. Ein Host-Wildcard wird nicht mehr damit verwechselt, Skripte von überall zuzulassen.
• DISALLOW_FILE_MODS schließt den Datei-Editor und stoppt Hintergrund-Updates. Keine der beiden Prüfungen wusste das. Wer dem eigenen Rat dieses Plugins folgte, ließ damit einen Befund stehen und machte aus einem anderen eine falsche Entwarnung.
• system.multicall verstärkt Passwortraten seit WordPress 4.4 nicht mehr, und die XML-RPC-Prüfung erkennt jetzt den Filter, mit dem die meisten Sicherheits-Plugins die Schnittstelle abschalten.
• Der Rat, einen anderen Anzeigenamen als den Anmeldenamen zu wählen, bringt nichts, weil der Autoren-Slug den Anmeldenamen behält, aus dem er erzeugt wurde.
• Anwendungspasswörter wurden auf jeder Website ohne HTTPS als abgeschaltet gemeldet, also genau dort, wo WordPress sie ohnehin verweigert.
• Ein Server, der den Quelltext einer PHP-Datei ausliefert, wurde gemeldet, als würde er sie ausführen. Das sind verschiedene Probleme mit verschiedenen Lösungen.
• .user.ini und .htpasswd standen in der Liste der Dateien, die zu löschen sind. Sie sind aktive Konfiguration, und wer die zweite löscht, sperrt Leute aus.
• Auf IIS riet die Prüfung zur .htaccess dazu, die Permalink-Einstellungen zu speichern, was dort eine web.config schreibt und nie eine .htaccess.
• Eine Rolle, die seit dem ersten Durchlauf lediglich hinzugekommen ist, wie es ein Shop- oder Mitgliedschafts-Plugin tut, wurde als Rolle mit Administrator-Rechten gemeldet.
• Installer und Shell-Skripte zwischen den Uploads gelten nicht mehr als Code, den der Server ausführt.
• Ein von 2.3.2 gespeicherter Durchlauf konnte beim ersten Seitenaufruf nach dem Update eine PHP-Warnung auslösen. Der Stummschaltungsstand, mit dem er gespeichert wurde, bleibt jetzt erhalten, bis ein Durchlauf dieser Version ihn ersetzt.
• Scans und Abfragen, die nicht abgeschlossen werden können, sagen das jetzt, statt Entwarnung zu geben: ein Scan der Core-Dateien, der an seine Grenze gestoßen ist, ein Plugin-Eintrag, der nicht abgerufen werden konnte, ein Datenbank-Dump, dessen URL nicht geantwortet hat.

Erklärungen

• Jeder der einundsechzig Einträge wurde gegen die Methode gelesen, die er dokumentiert. Vierzehn beschrieben Ergebnisse, die die Prüfung gar nicht kennt, oder schwiegen über die, die sie hat.
• Der Eintrag zu den Sicherheits-Headern nennt jetzt die Werte, die einzutragen sind, das Einzige, was ihm gefehlt hat. Die Einträge zu den Dateirechten sagen, wo sich Dateirechte ohne Shell-Zugang ändern lassen. Rund ein Dutzend Begriffe wird dort erklärt, wo sie zuerst auftauchen, statt vorausgesetzt zu werden.
• Die Warnung zum Tabellenpräfix nannte den falschen Mechanismus, und die Begründung für 640 gegenüber 440 bei wp-config.php war verdreht. Dateien im Webroot galten pauschal als harmlos, obwohl phpinfo.php die gesamte PHP-Umgebung ausgibt.

2.3.2

Behoben

• Die Prüfung auf ausführbare Dateien im Uploads-Verzeichnis meldete die leere index.php, die WordPress und die meisten Plugins in jeden Upload-Ordner legen, um die Verzeichnisauflistung zu unterbinden. Diese Dateien sind das Gegenteil eines Befunds, und weil die Prüfung als kritisch zählt, zog eine einzige davon eine sonst gesunde Website auf Note D herunter. Auf zwanzig Websites war die Note allein deshalb identisch. Die Prüfung liest so eine Datei jetzt, statt sie nach dem Namen zu beurteilen: Eine index.php besteht nur, wenn sie klein bleibt, keine Request-Daten liest, keine andere Datei einbindet, keine der Funktionen aufruft, die eine eingeschleuste Shell braucht, und nichts Eigenes ausgibt. Alles andere wird weiterhin gemeldet, index.php eingeschlossen.
• Jede gemeldete Datei trägt jetzt ihre Größe und, wenn eine index.php nicht bestanden hat, den Grund für die Meldung. Eine Schutzdatei hat ein paar hundert Bytes, die Zahl allein klärt also meist, was eine Datei ist.
• Die Zwei-Faktor-Abdeckung konnte ein Konto, das die Einrichtung nie abgeschlossen hat, nicht von einem unterscheiden, das sie schlicht nicht lesen konnte, und meldete beides als nicht ermittelt. Jedes unterstützte Plugin ist jetzt zusammen mit den Benutzer-Metadaten hinterlegt, die es schreibt. Ein installiertes Plugin, das niemand nutzt, wird damit als das gemeldet, was es ist: eine Lücke, samt der Konten ohne zweiten Faktor.
• Die Zwei-Faktor-Erkennung deckt jetzt ReportedIP Hive, Solid Security, Kadence Security, WP Defender und Google Authenticator ab. iThemes Security wurde zweimal umbenannt und kommt unter drei Ordnernamen vor, alle drei werden erkannt.

2.3.1

• Die Seite ist jetzt in drei Schritte gegliedert: Prüfung starten, Ergebnis lesen, den Rest durchgehen. Schritt zwei und drei sagen schon vor dem ersten Durchlauf, was sie enthalten werden, die Seite erklärt sich also selbst.
• Der Start-Button sagt, was er tut und wie lange es dauert, und der Hinweis zur temporären Datei steht direkt darüber.
• Das Ergebnis beginnt mit einem klaren Satz statt nur mit einem Buchstaben: wie viele Befunde jetzt Aufmerksamkeit brauchen, wie viele sich zu verbessern lohnen und wie viele Prüfungen nicht abgeschlossen werden konnten.
• Die Seite scrollt zum Ergebnis, wenn ein Durchlauf fertig ist, statt es unterhalb des sichtbaren Bereichs liegen zu lassen.
• Die Prioritätenliste heißt jetzt, was sie ist: To-do-Liste. Und sie sagt, dass man sie der Reihe nach abarbeitet.
• Ein Befund kann einen Link zu weiterer Hilfe enthalten. Der Zwei-Faktor-Befund verweist damit auf das Plugin Two Factor vom WordPress-Core-Team und auf ReportedIP Hive, das wir selbst entwickeln und auch so kennzeichnen.
• Drei Oberflächentexte und zwei Stylesheet-Regeln entfernt, die vom Neuaufbau übrig geblieben waren.

2.3.0

Neu aufgebaut

• Eine Registry ist jetzt die einzige Quelle für eine Prüfung: Kennung, Bezeichnung, Gruppierung, Dringlichkeit, Gewicht, Callback und Dokumentation lagen vorher an vier getrennten Stellen, die nichts synchron hielt. Ein Test erzwingt jetzt, dass sie übereinstimmen.
• Die Bewertung ist aus dem Browser nach PHP gewandert, damit ist das Ergebnis reproduzierbar, testbar und auch außerhalb des Dashboards verfügbar.
• Der admin-ajax-Endpunkt wurde durch REST-Routen unter cascr/v1 ersetzt, die drei Prüfungen gleichzeitig ausführen statt strikt eine nach der anderen.
• Ergebnisse werden gespeichert, damit der Bericht einen Durchlauf mit dem vorigen vergleichen kann.

Neu

• Fünfundzwanzig Prüfungen, darunter öffentlich lesbare Konfigurationsdateien und Repository-Ordner, Datenbank-Dumps im Webroot, Must-use-Plugins und Drop-ins, Änderungen an Rollen und Berechtigungen, das Inventar der Anwendungspasswörter mit letzter Nutzung, Zwei-Faktor-Abdeckung pro Administrator, REST-Schreibrouten ohne Authentifizierung, Ablauf des TLS-Zertifikats, Qualität von HSTS und CSP, Cookie-Attribute, gefälschte Client-Adressen und Besitzerwechsel bei Plugins.
• wp security-check run als WP-CLI-Befehl.
• Eine Prioritätenliste mit den fünf Dingen, die sich zuerst lohnen, ganz oben im Bericht.
• Ein Vergleich mit dem vorigen Durchlauf: neu nicht bestanden, behoben, geändert.
• Stummschalten mit Inhalts-Fingerprint, damit ein akzeptierter Befund wieder auftaucht, sobald er sich tatsächlich ändert.
• „Nicht ermittelt“ als eigenes Ergebnis, damit eine blockierte Anfrage kein Befund mehr ist und die Note nicht mehr beeinflusst.
• Export als Text, JSON und CSV.
• Die Filter cascr_registry und cascr_test_result.

Behoben

• Multisite meldete „Registrierung geschlossen“ auf einem Netzwerk, in dem sich jeder registrieren konnte, weil die Prüfung die Website-Option las, die Multisite ignoriert. Jetzt liest sie die Netzwerkeinstellung.
• Netzwerk-Administratoren fehlten in den Prüfungen zu Passwort, Administratoren, Zwei-Faktor und Anwendungspasswörtern. Sie haben jede Berechtigung, unabhängig von ihrer Rolle auf einer Website, eine Abfrage nach Rolle allein fand sie also nicht.
• Die Tabellenpräfix-Prüfung verglich auf Multisite das Präfix der einzelnen Website, sodass jede Website im Netzwerk aussah, als hätte sie ein eigenes.
• Ein Stored-Cross-Site-Scripting-Pfad: Befunde mit Website-Daten wie Plugin- oder Benutzernamen wurden per innerHTML in die Zusammenfassung geschrieben.
• Die Prüfungen der Dateirechte verglichen gegen exakt 0755 und meldeten deshalb 0750 und das verbreitete setgid 2755 als unsicher.
• WP_AUTO_UPDATE_CORE auf true wurde als Risiko gemeldet, obwohl es mehr Updates freischaltet als die empfohlene Einstellung.
• „Seit sechs Monaten nicht geändert“ galt als „veraltet“, was gut gepflegte Plugins markierte. Ersetzt durch Veröffentlichungsdatum, getestete WordPress-Version und Status im Plugin-Verzeichnis.
• Der Malware-Signatur-Scan durchsuchte wp-admin und wp-includes nach Zeichenketten wie eval( und $_GET[ und brauchte eine handgepflegte Liste von 180 Core-Dateien, um Ruhe zu geben. Ersetzt durch einen Abgleich mit der offiziellen WordPress-Dateiliste.
• Sicherheits-Header waren alles oder nichts. Sie werden jetzt pro Header bewertet, die Cross-Origin-Isolation-Header gelten als optional.
• Die Oberfläche folgte dem Farbschema des Betriebssystems und malte dunkle Kacheln auf das helle Dashboard. Jetzt folgt sie dem WordPress-Admin.

Geändert

• Eine Anfrage an die Startseite pro Durchlauf statt vier, und eine Update-Abfrage statt einer Anfrage pro installiertem Plugin.
• Doppelte Prüfungen zusammengelegt (PHP-Versionssupport, XML-RPC-Methoden, Begrenzung der Anmeldeversuche) und zwei gestrichen, die nie fehlschlagen konnten (jQuery-Version, Storage-Engine der Tabellen).
• Jeder Text der Oberfläche ist übersetzbar. Der Bericht war vorher fest auf Englisch, mit deutschem Datumsformat.
• Zahlen im Bericht nutzen richtige Pluralformen, statt immer den Plural anzunehmen.
• Der JavaScript-Alert wurde durch einen Admin-Hinweis und eine Screenreader-Ansage ersetzt.
• Die Testsuite läuft jetzt auch gegen Multisite, als blockierender Schritt vor jedem Release.

2.2.2

• PHP-Kompatibilität erweitert: Das Plugin läuft auf PHP 7.4 bis 8.5
• Benötigt WordPress 7.0 oder neuer
• Automatisierte Testsuite ergänzt, die jede Prüfung sowie die Berechtigungs- und Nonce-Sperren abdeckt
• Die Continuous Integration lintet auf sieben PHP-Versionen und lässt die Tests gegen WordPress 7.0 und die aktuelle Version laufen
• PHP-Warnung in den Update-Prüfungen für Themes und Plugins behoben, wenn ein Pfad nicht mehr existiert
• Ungenutzte Altlasten im Code entfernt und volle Konformität mit den WordPress Coding Standards erreicht

2.2.1

• Erste Veröffentlichung im WordPress.org-Plugin-Verzeichnis
• Plugin-Ordner, Hauptdatei und Textdomain in security-check-report umbenannt
• Spamhaus-IP-Blacklist-Test entfernt, der die Serveradresse ungefragt an einen Dritten schickte
• Ungenutzten Altcode und Dateien entfernt
• Laden der Übersetzungen ab WordPress 6.7 behoben
• Zertifikatsprüfung für die Testanfrage zur PHP-Ausführung aktiviert

2.2.0

• Oberfläche neu gestaltet, mit einem nativen Akkordeon aus details und summary
• Live-Suche über die Prüfungsdokumentation ergänzt
• Jede Prüfungsbeschreibung in ein einheitliches Format gebracht: was geprüft wird, warum das wichtig ist, was zu tun ist
• Farbschema vereinheitlicht und mehrere Layout-Probleme behoben