Ein Konfigurations-Audit für WordPress, das an Ihrer Konfiguration nichts verändert. 62 Prüfungen, eine Note von A bis F und ganz oben die fünf Aufgaben, die Sie zuerst angehen sollten. Neu in Version 2.4.1: der PHP2Shell-Check.
Kostenlos · GPLv2 · Keine Pro-Version · Keine Telemetrie
PHP2Shell ist der Name für zwei kritische Lücken im PHP-Kern, CVE-2026-109618 und CVE-2026-109619 (CVSS 9.2). Eine einzige Anfrage ohne Anmeldung kann Code auf dem Server ausführen, unter PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Team hat die Fixes am 21. Oktober 2026 veröffentlicht. Kein WordPress-Plugin kann PHP selbst patchen. Security Check Report sagt Ihnen aber innerhalb von Sekunden, ob Ihr Server das Update noch braucht.
Der Check liest die PHP-Version, mit der Ihre Website tatsächlich läuft, und antwortet in zwei Stufen:
| Grün | Der Fix ist nachgewiesen: PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 und neuer im jeweiligen Zweig, PHP 8.6 und neuer oder ein Ubuntu-Paket, das den Backport enthält. |
| Orange | Der Fix lässt sich an der Versionsnummer nicht ablesen. Aktualisieren Sie PHP oder lassen Sie sich den Backport von Ihrem Hoster bestätigen. Red Hat, Plesk, cPanel und selbst gebaute Pakete behalten nach einem Backport oft die alte Nummer. Orange ist deshalb eine Frage an Ihren Hoster, kein Urteil. |
Rot zeigt der Check nie, denn eine Versionsnummer allein beweist nicht, dass ein Server verwundbar ist. Der Check sendet nichts nach außen und betrachtet nur das laufende PHP. Nach einem Update starten Sie PHP-FPM oder den Webserver neu und führen den Check erneut aus. Hintergründe, gefixte Versionen und den Stand je Distribution finden Sie in unserem Beitrag PHP2Shell: kritische PHP-Lücken CVE-2026-109618/109619.
Die ausführliche Anleitung mit Mailvorlage für Ihren Hoster finden Sie im Beitrag PHP2Shell: So testen Sie selbst, ob Ihr Hoster PHP gepatcht hat. Läuft Ihre Website im Hosting von CMS ADMINS, spielen wir PHP-Sicherheitsupdates wie die gegen PHP2Shell selbst ein.
| Steckbrief (Stand 21.10.2026) | |
|---|---|
| Aktuelle Version | 2.4.1 |
| Getestet bis | WordPress 7.1.3 |
| Voraussetzungen | WordPress ab 7.0, PHP 7.4 bis 8.5 |
| Prüfungen | 62, in sechs Bereichen |
| Lizenz und Preis | kostenlos, GPLv2, keine Pro-Version |
| Quelltext | github.com/cmsadmins/security-check-report |
Kurz gesagt: Security Check Report ist ein kostenloses WordPress-Plugin von CMS ADMINS, das die Sicherheitskonfiguration Ihrer Website prüft, ohne sie zu verändern. Es vergibt eine Note von A bis F, nennt die fünf wichtigsten Aufgaben und zeigt seit Version 2.4.1, ob Ihr Server gegen PHP2Shell gepatcht ist. Es gibt keine Telemetrie und keine Pro-Version.
Security Check Report liest die Konfiguration Ihrer WordPress-Installation und bewertet sie in 62 Prüfungen. Das Ergebnis ist eine gewichtete Note von A bis F, ein Risikowert und eine Liste von fünf Aufgaben, abgeleitet aus Dringlichkeit und Punktzahl. Erst darunter folgt die vollständige Liste aller Befunde. Jeder Befund sagt, was gefunden wurde, warum es wichtig ist und was zu tun ist.
Wer schon einmal vor einem Security-Report mit 62 Zeilen saß und nicht wusste, wo anfangen, kennt das Problem, das diese Liste löst. Genau in diesem Moment bleiben Reports sonst ungelesen.
Ab dem zweiten Lauf öffnet die Seite nicht mehr mit dem Start-Button, sondern mit einer Übersicht: die Note, eine Zeile dazu, wo die Website beim ersten Lauf stand und wo sie heute steht, ein Balken pro gespeichertem Lauf, die nächsten fünf Aufgaben, was noch offen ist und was wann behoben wurde.
Der Report nach dem ersten Lauf: Note, Risikowert und die fünf wichtigsten Maßnahmen.
Damit Sie das richtige Werkzeug für die richtige Aufgabe wählen: Dieses Plugin ist ein Audit, kein Schutzschild. Eine Firewall schützt vor dem, was hereinkommt. Dieses Plugin prüft, was schon offen steht.
| Keine Firewall | Es blockiert nichts und fängt keine Requests ab. |
| Kein Malware-Scanner | Es vergleicht Core-Dateien mit den offiziellen Prüfsummen und sucht injizierten Code in der Options-Tabelle. Es durchsucht keinen Plugin- oder Theme-Code nach Signaturen und entfernt nichts. |
| Keine Schwachstellen-Datenbank | Es meldet, wenn ein Plugin veraltet, verwaist oder aus dem Verzeichnis entfernt wurde. Einzelne CVEs schlägt es nicht nach. Die einzige Ausnahme ist PHP2Shell, weil diese Lücke jede PHP-Website zugleich trifft. |
| Kein Auto-Fixer | Jeder Befund kommt mit einer Anleitung. Umsetzen müssen Sie selbst, oder Sie geben es an jemanden, der das täglich macht. |
| Kein Monitor | Im Hintergrund läuft nichts, nichts ist zeitgesteuert, es werden keine Mails verschickt. Eine Prüfung läuft, wenn Sie sie starten. |
| Kein Sicherheitsversprechen | Note A heißt: nichts Wesentliches offen. Es heißt nicht: sicher. |
62 Prüfungen in sechs Bereichen. Jede Prüfung bringt eine eigene, durchsuchbare Erklärung mit: was geprüft wird, warum das wichtig ist und was zu tun ist.
WordPress-Version, PHP-Version gegen die veröffentlichten End-of-Life-Termine, PHP2Shell-Fix, automatische Core-Updates, Integrität der Core-Dateien gegen die offiziellen Prüfsummen, fremde Dateien in den Core-Verzeichnissen, ausstehende Updates, ungenutzte Plugins und Themes, verwaiste oder aus dem Verzeichnis entfernte Plugins, Plugins mit neuem Autor, Must-Use-Plugins und Drop-ins, weitere WordPress-Installationen daneben.
Debug-Modus, öffentlich lesbares Debug-Log, Theme- und Plugin-Editor, Code-Installation aus dem Dashboard, Authentifizierungsschlüssel und Salts, Tabellenpräfix, Rechte des Datenbank-Users, ob der Scheduler tatsächlich läuft, Größe der Autoload-Optionen, injizierte Inhalte in der Options-Tabelle, Backups, Login-Schutz, Passwort-Richtlinie.
Rechte von wp-config.php, Uploads-Ordner und Core-Verzeichnissen, weltweit beschreibbare Pfade, ausführbare Dateien zwischen den Medien, ob der Server PHP aus dem Uploads-Ordner ausführt, ausgelieferte Konfigurations- und Backup-Dateien, lesbare .git-, .svn- und .hg-Ordner, Datenbank-Dumps im Web-Root, Reste abgebrochener Updates, Verzeichnislisting.
Erratbare Passwörter, vorhersehbare Admin-Namen, Anzahl und Ruhezustand der Administratorkonten, Rollen unterhalb von Administrator mit zu weitreichenden Rechten, offene Registrierung und die vergebene Rolle, Zwei-Faktor-Abdeckung je Administrator, Inventar der Application Passwords mit letzter Nutzung und Herkunft.
HTTPS und Weiterleitung von http, Ablauf des TLS-Zertifikats und ausgehandeltes Protokoll, Security-Header und deren Qualität statt bloßer Anwesenheit, Cookie-Attribute, CORS, offengelegte Software-Versionen, veraltete Discovery-Tags, XML-RPC, User-Enumeration, REST-Routen, die Schreibzugriffe ohne Rechteprüfung annehmen, und ob sich die Client-Adresse über Forwarded-Header fälschen lässt.
Ob KI-generierte Inhalte maschinenlesbar gekennzeichnet sind und ob Besucher erfahren, wenn sie mit einem KI-System sprechen, wie es Artikel 50 der EU-KI-Verordnung seit dem 2. August 2026 verlangt. Eine Website ohne KI-Ausgaben hat nichts zu kennzeichnen, deshalb warnt diese Prüfung nur und bewegt die Note kaum.
Alle Prüfungen, gruppiert und filterbar. Jeder Befund lässt sich aufklappen und zeigt Details und die passende Maßnahme.
Oben im Report stehen fünf Aufgaben, abgeleitet aus Dringlichkeit und Punktzahl, deterministisch und ohne KI. Erledigen Sie eine, rückt die nächste nach. Die vollständige Befundliste kommt erst danach.
Jede Aufgabe hat einen Button, der genau diese eine Prüfung erneut ausführt und innerhalb von Sekunden antwortet. Eine Einzelprüfung schreibt keinen Punkt in den Verlauf, und die Seite sagt das auch, denn eine aus mehreren Durchgängen zusammengesetzte Note ist keine in einem Lauf gemessene Note.
Das Plugin speichert die letzten 24 Läufe. Der allererste bleibt dauerhaft erhalten, damit der Ausgangspunkt sichtbar bleibt. Dazu kommen der Fortschritt je Bereich, eine Zahl am Menüeintrag, ein Widget auf dem Dashboard und ein Hinweis, sobald der letzte vollständige Lauf älter als 30 Tage ist.
Ab dem zweiten Lauf zeigt der Report, was neu fehlgeschlagen ist, was behoben wurde und was sich verändert hat. Der zweite Lauf ist der Moment, in dem die meisten Werkzeuge langweilig werden. Hier wird er interessanter.
Wenn eine Prüfung keine Antwort bekommt, etwa weil ein ausgehender Request blockiert ist, lautet das Ergebnis: nicht feststellbar. Das fließt nicht in die Note ein, weder positiv noch negativ. Andere Werkzeuge melden bei einem Timeout ein Problem. Das erzeugt Fehlalarme, und Fehlalarme bringen Leute dazu, den ganzen Report zu ignorieren.
Jede Prüfung hat eine Dringlichkeit mit festem Gewicht: kritisch 3,0, hoch 2,0, mittel 1,5, niedrig 1,0. Die Note ist das gewichtete Risiko im Verhältnis zum schlechtesten möglichen Ergebnis. Ein fehlgeschlagener kritischer Check zieht das Ergebnis auf mindestens D, damit ein ernstes Problem nicht von fünfzig bestandenen Kleinigkeiten verdeckt wird.
Einen akzeptierten Befund können Sie stummschalten. Das Plugin merkt sich dabei einen Fingerabdruck dessen, was gemeldet wurde. Ändert sich der Inhalt, taucht der Befund wieder auf. Das ist der Unterschied zwischen davon wissen und blind dafür geworden sein.
Welche Application Passwords existieren, wann erstellt, wann zuletzt benutzt, von welcher IP. Application Passwords umgehen die Zwei-Faktor-Authentifizierung per Design. Ein nie benutztes von vor zwei Jahren bei einem Admin-Konto ist der eigentliche Befund, nicht die Frage, ob die Funktion aktiviert ist.
Gegenüber Ihrer Konfiguration arbeitet das Plugin rein lesend: Es ändert keine Einstellung, keine Datei und kein Konto. Es gibt genau eine Ausnahme, die wir lieber selbst erklären: Um festzustellen, ob Ihr Server eine PHP-Datei im Uploads-Ordner ausführen würde, legt es eine Datei mit zufälligem Namen an, ruft sie einmal per HTTP ab und löscht sie im selben Request wieder. Ein Shutdown-Handler entfernt die Datei auch dann, wenn PHP dazwischen abbricht, und Reste eines früher abgebrochenen Laufs werden vor dem nächsten Lauf aufgeräumt. Genau diese Einstellung macht aus einer Upload-Lücke eine Übernahme der Website.
In der Datenbank speichert es seine eigenen Ergebnisse: den letzten und den vorletzten Lauf, den Verlauf der letzten 24 Läufe, stummgeschaltete Befunde mit Fingerabdruck, eine Baseline aus dem ersten Lauf (Plugin-Autoren, Rollendefinitionen, Must-Use-Plugins und Drop-ins), die Zahl der offenen Befunde für den Menüeintrag und den Zeitpunkt Ihrer Zustimmung zum Lauf. Im User-Meta landen ein Login-Zeitstempel pro Konto und die Information, ob jemand den Erinnerungshinweis abgeschaltet hat. Beim Löschen des Plugins wird alles entfernt.
Externe Verbindungen gibt es ausschließlich zu api.wordpress.org, zu denselben Endpunkten, die WordPress selbst für Update-Prüfungen nutzt, und zur eigenen Site. Für die Zertifikatsprüfung öffnet das Plugin eine direkte TLS-Verbindung zum eigenen Hostnamen auf Port 443. Telemetrie gibt es keine, es werden also keine Daten an uns gesendet.
Sie finden das Plugin im offiziellen WordPress-Verzeichnis: in Ihrem WordPress-Admin unter Plugins, Installieren, Suche nach Security Check Report. Oder direkt unter wordpress.org/plugins/security-check-report. Nach dem Aktivieren öffnen Sie im Admin-Menü den Eintrag Security Check und starten einen Lauf. Dafür ist die Berechtigung manage_options nötig, auf einer normalen Website also ein Administratorkonto.
Auf der Kommandozeile liefert wp security-check run dieselbe Note wie die Oberfläche, --format=json das vollständige Ergebnis und --failed-only nur das, was Aufmerksamkeit braucht. Ein Lauf per WP-CLI speichert nichts. Exporte gibt es als Text, JSON und CSV.
Voraussetzungen: WordPress ab 7.0, PHP 7.4 bis 8.5. Das Plugin ist kostenlos, steht unter GPLv2, und es gibt keine Pro-Version und keinen Upsell im Plugin. Es bewirbt keine Dienstleistung, zeigt keine Werbung und funktioniert vollständig ohne Kundenbeziehung.
Der PHP2Shell-Check liest die PHP-Version, mit der Ihre Website läuft. Grün bedeutet: Der Fix ist nachgewiesen (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer, PHP 8.6 und neuer oder ein Ubuntu-Paket mit Backport). Orange bedeutet: Der Fix lässt sich an der Versionsnummer nicht ablesen. Aktualisieren Sie PHP oder lassen Sie sich den Backport von Ihrem Hoster bestätigen.
Nein. Jede Prüfung liest einen Zustand und berichtet darüber. Die einzige Ausnahme ist eine temporäre PHP-Datei mit zufälligem Namen im Uploads-Ordner, die im selben Request wieder gelöscht wird. Nur so lässt sich prüfen, ob der Server dort PHP ausführen würde.
Weder noch. Das Plugin findet Konfigurationsschwächen und offene Stellen. Es blockiert keinen Datenverkehr und bereinigt keine infizierte Website. Hinweise auf eine Kompromittierung wie veränderte Core-Dateien oder ausführbare Dateien im Uploads-Ordner sind ein Ausgangspunkt für eine Untersuchung, kein Urteil.
Nein. Es verbindet sich nur mit api.wordpress.org und mit Ihrer eigenen Website. Es gibt keine Telemetrie und keine Rückmeldung an den Plugin-Autor.
A: nichts Wesentliches offen. B: kleinere Verbesserungen möglich. C: mehrere Punkte sollten angegangen werden. D: deutliche Schwächen, bald handeln. F: kritisch, sofort handeln. Note A heißt nicht, dass eine Website sicher ist.
Weil die Prüfung keine Antwort bekommen hat, meist wegen einer blockierten ausgehenden Anfrage oder einer Datei, die nicht gelesen werden darf. Das gilt bewusst nicht als Befund und verändert die Note in keine Richtung.
Monatlich als Grundtakt, dazu nach jeder größeren Änderung wie einer Migration, einem neuen Plugin oder einem Serverumzug. Ist der letzte vollständige Lauf älter als 30 Tage, weist ein Hinweis im Dashboard darauf hin.
Ja, pro Site. Wer auf einer Site manage_options hat, kann dort prüfen. Registrierung wird als Netzwerkeinstellung gelesen, und Netzwerk-Administratoren fließen in die Konten-, Passwort- und Zwei-Faktor-Prüfungen ein. Eine netzwerkweite Übersicht gibt es nicht.
WordPress ab 7.0 und PHP 7.4 bis 8.5. Version 2.4.1 ist bis WordPress 7.1.3 getestet.
Nichts. Es steht unter GPLv2, es gibt keine Pro-Version und keinen Upsell im Plugin. Es funktioniert gleich, ob Sie jemals mit uns sprechen oder nicht.
Das ist die Checkliste, die wir bei jedem Wartungskunden abarbeiten. Wir haben sie in ein Plugin gepackt und verschenkt.
Das Werkzeug ist an echten Kundensites gewachsen. Wenn Sie die Befunde nicht selbst abarbeiten wollen, wissen Sie jetzt, wen Sie fragen können.
Bei unseren Kunden gehört das Abarbeiten zur Betreuung: Im Hosting von CMS ADMINS spielen wir PHP-Sicherheitsupdates selbst ein, mit der WordPress-Wartung kümmern wir uns um Updates von WordPress, Plugins und Themes.
Security Check Report im WordPress-Verzeichnis
Anleitung: PHP im Uploads-Ordner blockieren (Apache und nginx)
Anleitung: Security-Header in Apache und nginx setzen
PHP2Shell: kritische PHP-Lücken CVE-2026-109618/109619
Anleitung: PHP2Shell beim eigenen Hoster selbst testen
Quelltext und Issues auf GitHub
WordPress-Sicherheit: Härtung und Betreuung durch CMS ADMINS
Hosting von CMS ADMINS mit PHP-Sicherheitsupdates
WordPress-Wartung: Updates für WordPress, Plugins und Themes
WordPress gehackt: Soforthilfe bei einem akuten Vorfall