WordPress-Audit? Beginnen Sie mit Ihren Plugins

Zusammenfassung

Die meisten WordPress-Sicherheitsaudits sind rückwärts ausgerichtet: Sie betonen Core-Updates und Scanner-Berichte, während die Schwachstellen, die tatsächlich beißen, in Plugins leben. Ein SANS-Whitepaper ergab, dass über 96% der Schwachstellen im Ökosystem von Drittanbieter-Plugins stammen, und etwa 43% benötigen keine Authentifizierung. Dieser Artikel führt durch ein Plugin-zentriertes Audit für ein kleines internes Marketing-Team und nutzt die Geschichte einer Website, die gehackt wurde, weil alle die falsche Ebene gescannt haben. Sie lernen, jedes Plugin zu inventarisieren und zu klassifizieren, nicht authentifizierte Angriffsflächen zu testen, Benutzer und Protokolle manuell zu überprüfen und Ergebnisse in eine Risikosprache zu übersetzen, die ein nicht-technischer Chef versteht. Das Ergebnis ist ein vierteljährliches Triage-Ritual statt einer Checklisten-Übung.

Die meisten WordPress-Sicherheitsaudits sind Theater. Sie verbringen einen Nachmittag damit, den Core zu aktualisieren, das Admin-Passwort zu ändern und einen Plugin-Scanner auszuführen, der stolz „Keine kritischen Probleme" meldet. In der Zwischenzeit sitzt das Plugin, das Datei-Uploads akzeptiert hat und vor drei Jahren zuletzt aktualisiert wurde, still in Ihrem Uploads-Verzeichnis und wartet auf jemanden, der nicht auf der Gästeliste steht.

Die Zahlen belegen das. Ein SANS-Whitepaper zum Scannen von WordPress-Plugins ergab, dass mehr als 96% der Schwachstellen im WordPress-Ökosystem von Drittanbieter-Plugins stammen, bei Themes 4% und beim Core unter 1%. Etwa 43% dieser Schwachstellen können ohne Authentifizierung ausgenutzt werden. Wenn Ihr Audit also die meiste Energie auf den Core verwendet, untersuchen Sie die Bäume, während im Plugin-Verzeichnis nebenan ein Waldbrand ausbricht.

Das ist kein Aufruf, in Panik zu geraten, was den Core betrifft. Core-Schwachstellen wie die wp2shell-RCE-Fehler, für die kürzlich öffentliche Exploits veröffentlicht wurden, sollten am Tag ihrer Ankündigung gepatcht werden. Aber sie sind selten genug, dass sie nicht den Großteil Ihrer Audit-Stunden verdienen. Der Großteil gehört den Plugins, und dort beginnt der eigentliche Workflow.

Stellen Sie sich das Vorher-Szenario vor: Ein Sonntagmorgen, Ihre Website leitet auf eine Casino-Seite weiter, und Ihr Chef schreibt: „Ich dachte, wir hätten Sicherheit." Sie hatten Sicherheit — Sie hatten ein Checklisten-Audit. Das Nachher-Szenario ist ein Triage-System, das Plugins als das behandelt, was sie tatsächlich sind: eine Angriffsfläche. Es testet sie von außen und prüft die Dinge, die Scanner nicht sehen können.

Sie sind in einem kleinen Marketing-Team mit einer WordPress-Website, die seit 2017 läuft. Sie hat ein individuelles Event-Registrierungs-Plugin, das ein Freelancer 2019 gebaut hat, ein Kontaktformular-Plugin mit einem Datei-Upload-Feld und ein Slider-Plugin, das verkauft wurde und keine öffentliche Update-Seite mehr hat. Das ist kein ungewöhnlicher Stack. Hier beginnt Ihr Audit.

---

Das Plugin-Inventar ist Ihre Sicherheitsrichtlinie

Nehmen Sie jedes Plugin und Theme in Ihr Inventar auf. Notieren Sie die Version, das letzte Aktualisierungsdatum, ob der Anbieter noch aktiv ist und ob es tatsächlich jemand nutzt. Klassifizieren Sie dann jedes einzelne in eine Kategorie: gepflegt und genutzt, gepflegt und ungenutzt, verlassen aber genutzt, verlassen und ungenutzt. Entfernen Sie die ungenutzten sofort. Ignorieren Sie das „Es kostet nur 50 Dollar im Monat"-Argument – ein ungenutztes Plugin ist eine Haftung, kein Feature. Bei den verlassenen, aber genutzten Entscheiden Sie: Ersetzen Sie es oder akzeptieren Sie das Risiko und schreiben Sie es in ein Risikoregister, das Ihr Chef gesehen hat.

Das Event-Registrierungs-Plugin fällt in die Kategorie „verlassen, aber genutzt". Es nimmt Zahlungen entgegen und sendet Bestätigungs-E-Mails, und es zu ersetzen ist ein Projekt, also behalten Sie es vorerst. Aber Sie schreiben eine Notiz: „Das ist die wahrscheinlichste Quelle eines künftigen Einbruchs", und setzen es an die Spitze der Testliste.

Angriffsfläche	Anteil an bekannten WordPress-Schwachstellen	Audit-Priorität
Drittanbieter-Plugins	Über 96%	Höchste – Inventar, Scan, Test, Ersetzen
Themes	Etwa 4%	Mittel – nur wenn benutzerdefiniert oder veraltet
WordPress-Core	Unter 1%	Niedrig – gepatcht halten, weitermachen

Als SecurityWeek im Jahr 2024 mehr als 8.000 neue WordPress-Schwachstellen zählte, war die überwiegende Mehrheit dieser Art: Plugin-Probleme, keine Core-Patches. Ein Scanner informiert Sie über diejenigen, die offengelegt und mit einer CVE versehen wurden. Er informiert Sie nicht über den benutzerdefinierten Freelancer-Code ohne CVE, weil sich niemand jemals genau damit befasst hat. Dieser manuelle Blick ist Ihre Aufgabe. Eine tiefergehende Anleitung zu plugin-spezifischen Checks finden Sie in diesem Leitfaden zum Auditieren Ihrer WordPress-Plugins auf Schwachstellen.

---

Testen Sie es wie ein Fremder: die 43%, die kein Passwort benötigen

Ihr Scanner hat Ihnen bereits gesagt, dass nichts falsch ist. Jetzt tun Sie, was er nicht kann: Sondieren Sie die Website von außen, ohne Anmeldung. Beginnen Sie mit jedem Datei-Upload-Feld, jedem Formular, das ein POST verarbeitet, und jedem Admin-Ajax-Endpunkt. Prüft der Upload tatsächlich den Dateiinhalt oder nur die Erweiterung? Wo landen die hochgeladenen Dateien, und kann der Webserver PHP in diesem Verzeichnis ausführen? Die 43% der Plugin-Schwachstellen, die keine Authentifizierung erfordern, sitzen normalerweise genau an diesen Stellen: nicht authentifiziertes gespeichertes XSS, beliebiger Datei-Upload und PHP-Objektinjektion.

Das Kontaktformular-Plugin ermöglicht Besuchern, einen Lebenslauf anzuhängen. Es benennt die Datei mit dem ursprünglichen Dateinamen des Besuchers um. Sie laden also „resume.php" hoch, und es speichert sie in einem /uploads/contact/-Ordner, der per Design beschreibbar ist. Wenn der Server außerdem das Ausführen von PHP in diesem Verzeichnis erlaubt, hat der Angreifer sofort eine Webshell. Fastly hat die aktive Ausnutzung von nicht authentifiziertem gespeichertem XSS in WordPress-Plugins dokumentiert – das ist kein Nischenrisiko. Ihr Test ist einfach: Erstellen Sie eine Datei mit bekanntem Inhalt, laden Sie sie hoch und prüfen Sie, ob sie mit ihrem ursprünglichen Namen und Typ zurückkommt. Versuchen Sie dann, eine .php-Datei hochzuladen. Wenn sie als .php zurückkommt, haben Sie gerade ein ausnutzbares Loch gefunden.

Hier bricht auch das Argument „aber unser Sicherheitsplugin hat eine WAF" zusammen. Eine WAF kann eine bekannte Nutzlast blockieren, aber die Pfadnormalisierungsregeln, auf die sie sich stützt, weichen oft von dem ab, was der Server tatsächlich tut. Der OWASP Web Security Testing Guide ist eine bessere Referenz als jedes Dashboard: Er beschreibt, wie man Datei-Upload-Fehler und gespeichertes XSS methodisch testet. Und wenn Sie feststellen, dass das Plugin verlassen ist, ist es Zeit, das Aufräumprotokoll anzuwenden: Die versteckte Gefahr verlassener WordPress-Plugins erklärt, warum es schlimmer ist, eine tote Erweiterung zu behalten, als sie zu entfernen und Ihren Workflow anzupassen.

---

Was der Scanner nicht sehen kann: Benutzer, Protokolle und alter Code

Dynamische Tests erfassen, was gerade exponiert ist. Die manuelle Überprüfung erfasst, was sich bereits im Inneren befindet. Beginnen Sie mit Benutzerkonten: Öffnen Sie die Admin-Liste und suchen Sie nach Konten, die Sie nicht erstellt haben. Ein Administrator namens „support" mit einer Free-Mail-Adresse und keinem Menschen dahinter ist ein Hintertürchen, kein Kollege. Überprüfen Sie Dateizeitstempel in wp-content/uploads auf kürzlich geänderte Dateien, die nicht zu Ihrem Inhalt gehören. Überprüfen Sie das Server-Zugriffsprotokoll auf Anfragen, die wie ein Bot-Curl-Befehl statt wie ein Browser einer Person aussehen.

Das Event-Plugin hat einen Upload für „Speaker-Fotos", der in uploads/event-headshots/ speichert. Während des Tests finden Sie eine Datei, die nicht von Ihnen stammt – eine kleine PHP-Datei mit einem zufällig aussehenden Namen. Das ist Ihre Webshell. Sie gelangte durch denselben Upload-Fehler dorthin, den Sie vor zwei Wochen getestet haben, und ein Scanner würde sie immer noch nicht „sehen", weil es keine Plugin-Schwachstelle ist; es ist ein Beweis für eine. Die manuelle Überprüfung findet sie, löscht sie und überprüft das Protokoll auf die IP-Adresse, die sie dort abgelegt hat. Invicti hat festgestellt, dass PHP-Objektinjektion in Plugins zunimmt, und sie ist für Black-Box-Scans nahezu unsichtbar, da das bösartige Objekt erst während der Ausführung materialisiert. Der einzige Weg, sie zu erkennen, besteht darin, Code auf gefährliche Muster wie den Aufruf von unserialize() auf benutzergenerierte Eingaben zu lesen. Ein paar hundert Zeilen des benutzerdefinierten Plugins zu lesen, ist billiger als die Zahlung eines Incident-Response-Honorars.

Hier stößt auch der Standardratschlag „installieren Sie einfach mehr Sicherheitsplugins" an seine Grenzen. Das Übereinanderschichten von drei Sicherheitsplugins führt zu sich überschneidenden WAF-Regeln, die sich gegenseitig blockieren, zu einer Flut doppelter Protokoll-E-Mails und gelegentlich zu einem „Sie sind gesperrt"-Fehler beim eigenen Admin-Login. Ein aktives Sicherheitsplugin, gut konfiguriert, reicht aus. Lesen Sie mehr darüber, warum zu viele Sicherheitsplugins nach hinten losgehen, bevor Sie etwas anderes auf den Stapel legen.

---

Ihrem Chef die Wahrheit sagen, ohne Panik auszulösen

Ihr Chef kümmert sich nicht um CVSS-Scores oder PHP-Objektinjektion. Er kümmert sich darum, dass die Website ausfällt, der Shop keine Bestellungen annimmt und das IT-Budget. Die Übersetzung ist einfach: „Dieses Plugin hat eine bekannte nicht authentifizierte Remote-Codeausführungs-Schwachstelle. Ein Fremder kann unsere Website-Inhalte löschen oder ein Hintertürchen installieren. Wir müssen es in diesem Quartal ersetzen." Zeigen Sie dann die Prioritätenliste: Ersetzen Sie das Event-Plugin, deaktivieren Sie den Datei-Upload des Kontaktformulars, bis es Dateitypen ordnungsgemäß validiert, rotieren Sie alle Admin-Anmeldedaten und planen Sie die nächste vierteljährliche Überprüfung.

Sie haben auch einen Sprachvorteil: CISA pflegt den Katalog „Known Exploited Vulnerabilities", der genau zeigt, welche veröffentlichten Schwachstellen aktiv in freier Wildbahn ausgenutzt werden. Wenn eines Ihrer Plugins dort auftaucht, ist das Argument nicht mehr theoretisch – ein bekannter Exploit existiert, und Sie sind auf der Uhr. Wenn nicht, nutzen Sie ihn trotzdem als Standard dafür, was „dringend" bedeutet. CISAs Verfolgung macht es einfacher, einen nicht-technischen Chef zu überzeugen, dass dies keine Phishing-E-Mail ist; es ist eine öffentliche Datenbank darüber, was Angreifer gerade tun. Wenn das Quartal endet, haben Sie einen Behebungs-Workflow, keine einmalige Checklisten-Übung. Ein Workflow zur Umwandlung von Schwachstellen in einen Patch-Zyklus hält die Gewohnheit am Leben.

---

Das Vorher war eine kaputte Website, eine hektische E-Mail und ein sauberer Scanner-Bericht, der besagte, dass nichts falsch sei. Das Nachher ist ein vierteljährliches Ritual: Inventar, Klassifizierung, Test von außen, Überprüfung von Benutzern und Protokollen, und Aufschreiben der Entscheidungen, die Sie getroffen haben, und der Risiken, die Sie akzeptiert haben. Der Scanner wird zu einer Karte, wo man suchen muss, nicht zu einem Gesundheitszeugnis. Die Plugins werden zu einer Liste, die Sie beim Namen kennen. Und wenn Ihr Chef das nächste Mal nach dem Audit fragt, haben Sie eine Antwort, die nicht darin besteht, die Daumen zu drücken.