WordPress-Sicherheitsaudit

#WordPress-Sicherheitsaudit an einem echten Beispiel

Das Unangenehme ist, wie normal das ist. Die Site funktionierte. Sie sah gut aus. Der Eigentümer hatte keinen Grund, etwas zu vermuten, denn veraltete Plugins zeigen keine Symptome, bis sie ausgenutzt werden. Das Audit existierte, um die Lücke zu finden, bevor es jemand anderes tat.

#Warum veraltete WordPress-Plugins ein Sicherheitsrisiko sind

Ein Plugin ist sicher, solange es gepatcht wird. In dem Moment, in dem eine Schwachstelle als CVE veröffentlicht wird und Sie nicht aktualisiert haben, ist der Exploit öffentliches Wissen und Ihre installierte Version ein benanntes Ziel für automatisierte Scanner. Angriffe auf WordPress sind überwiegend blind und automatisiert. Bots durchkämmen das Netz nach bekanntermaßen verwundbaren Versionen beliebter Plugins, sodass der Betrieb eines alten Elementor oder Contact Form 7 kein abstraktes Risiko ist. Es ist ein beworbenes.

Auf dieser Site:

• Elementor 3.11.1 lag unterhalb der Fixes für fünf im NVD gelistete CVEs: SQL injection (CVE-2023-0329, behoben in 3.12.2), fehlende Autorisierung (CVE-2023-33922, behoben in 3.13.3), cross-site scripting (CVE-2023-47505) und fehlerhafte Authentifizierung (CVE-2023-47504, die das NVD mit 9,8 als kritisch einstuft), beide betreffen Versionen bis 3.16.4, sowie ein gefährlicher Datei-Upload (CVE-2023-48777, behoben in 3.18.2). Jede dieser fünf war in Produktion aktiv.
• Contact Form 7 5.8 war anfällig für CVE-2023-6449, eine Lücke für beliebige Datei-Uploads im Plugin selbst (Versionen bis einschließlich 5.8.3), die einem angemeldeten Nutzer mit Redakteursrechten erlaubte, beliebige Dateien hochzuladen. Für sich allein führt sie selten zur Codeausführung, verkettet mit einer zweiten Lücke wie einer Local File Inclusion aber schon.

Keines der beiden Plugins war ungewöhnlich. Beide laufen auf einem riesigen Anteil von WordPress-Sites. Genau deshalb sind ihre bekannten Schwachstellen die Zeit eines Scanners wert. Patchstack misst im Bericht State of WordPress Security in 2026 die Medianzeit von der öffentlichen Enthüllung einer hochwirksamen Schwachstelle bis zur Massenausnutzung mit fünf Stunden. Das Fenster zwischen „CVE ist öffentlich“ und „ein Bot scannt schon Ihre Version“ zählt in Stunden, nicht in Wochen.

Derselbe Patchstack-Bericht zählt für 2025 insgesamt 11.334 neue Schwachstellen im WordPress-Ökosystem: 91 Prozent in Plugins, 9 Prozent in Themes und nur 6 Meldungen im WordPress-Core, alle mit niedriger Priorität. Ein Audit, das bei der Core-Version stehen bleibt, prüft den kleinsten Teil der Angriffsfläche.

Aufgegebene Plugins verschärfen das Bild. Wenn der Autor keine Fixes mehr liefert, schließt sich ein CVE nur durch Entfernen oder Austausch des Werkzeugs. Ein totes Plugin „für alle Fälle“ in wp-content/plugins/ hält die Angriffsfläche auch nach Deaktivierung lebendig, wenn die Dateien noch auf der Platte liegen und über bekannte Pfade erreichbar sind.

#In welcher Reihenfolge WordPress-CVEs patchen

Das WordPress-Backend zeigt Updates alphabetisch oder nach Datum. Sicherheits-Triage sortiert anders:

1. Schwere und Angriffsklasse. Datei-Upload, Remote-Code-Ausführung und SQL injection gehen vor XSS, das einen eingeloggten Admin braucht.
2. Erforderliche Rechte. Eine unauthentifizierte Lücke oder eine mit Abonnenten-/Redakteursrolle hat Vorrang vor einer, die einen Administrator braucht, von dem Sie einen haben und den Sie mit 2FA absichern.
3. Ob der verwundbare Codepfad genutzt wird. Ein CVE in einer optionalen Funktion zählt nur auf Sites, auf denen diese Funktion erreichbar ist. Das Audit prüft, ob die betroffene Funktion auf der Site tatsächlich genutzt wird, nicht nur, ob das Plugin installiert ist.
4. Ob ein öffentlicher Exploit existiert. Wenn ein Proof of Concept in Threat-Intel kursiert, schrumpft die Reaktionszeit auf Stunden. Patchstack hält außerdem fest, dass 46 Prozent der Schwachstellen zum Zeitpunkt der Enthüllung keinen Patch haben, sodass die einzige sofortige Antwort oft das Abschalten der Funktion oder des Plugins ist, nicht „Aktualisieren klicken“.

Auf der besprochenen Site war die Triage klar: zuerst Contact Form 7 (Upload), dann Elementor (Injection und XSS), dann Aufräumen der übrigen Plugins ohne aktives CVE. CVE-Nummer und Veröffentlichungsdatum ersetzen diese Reihenfolge nicht.

#CVSS-Score einer WordPress-Plugin-CVE richtig lesen

Schwachstellendatenbanken versehen fast jedes CVE mit einem CVSS-Basiswert. Die CVSS-v3.1-Spezifikation von FIRST ordnet die Zahl einer Stufe zu: 0,0 ist None, 0,1 bis 3,9 Low, 4,0 bis 6,9 Medium, 7,0 bis 8,9 High und 9,0 bis 10,0 Critical. Berechnet wird der Wert aus Metriken wie Attack Vector, Attack Complexity, Privileges Required und User Interaction, und der Vektor neben der Zahl sagt mehr über Ihre Site als die Zahl selbst.

CVE-2023-6449 zeigt das. Der NVD-Eintrag führt zwei CVSS-3.1-Werte für dieselbe Lücke:

Der einzige Unterschied ist Attack Complexity. Wordfence setzte High, was nach der FIRST-Definition bedeutet, dass der Erfolg von Bedingungen außerhalb der Kontrolle des Angreifers abhängt; die NVD setzte Low. Diese eine Metrik hebt die Einstufung von Medium auf High. Einig sind sich beide bei PR:H, hohe Privilegien, also die Stufe, die FIRST als weitreichende Kontrolle beschreibt, etwa Administratorrechte. Für die Triage ist das der nützliche Teil: Auf einer Site mit einem einzigen Redakteurskonto mit Zwei-Faktor-Anmeldung ist das praktische Risiko geringer als auf einer Site, auf der sich ein Dutzend Redakteurszugänge auf Team, Agentur und Freelancer verteilen.

FIRST empfiehlt außerdem, den Basiswert um Temporal- und Environmental-Werte zu ergänzen. Die CVSS-v4.0-Spezifikation, veröffentlicht am 1. November 2023, hält fest, dass Anbieter wie Produkthersteller und die NVD meist nur Basiswerte veröffentlichen, gekennzeichnet als CVSS-B. Der Umgebungsteil, also wie stark die verwundbare Funktion auf Ihrer konkreten Site exponiert ist, bleibt Aufgabe des Audits.

#Wer vergibt die CVE-Nummer für eine WordPress-Plugin-Schwachstelle

CVE-Nummern vergeben CVE Numbering Authorities (CNA): Hersteller, Forschende, CERTs und andere Organisationen, die das CVE-Programm berechtigt, in ihrem jeweiligen Zuständigkeitsbereich IDs zuzuweisen und CVE-Records zu veröffentlichen. Patchstack, Wordfence und WPScan stehen alle als CNA auf dieser Partnerliste. Der Record zu CVE-2023-6449 auf cve.org nennt Wordfence als vergebende Stelle: Die ID wurde am 30. November 2023 reserviert und am 1. Dezember 2023 veröffentlicht. Der Record führt Contact Form 7 bis einschließlich 5.8.3 als betroffen und verlinkt die Codeänderung zwischen 5.8.3 und 5.8.4 als Fix. Die NVD ergänzt danach ihre eigene Analyse, daher stammt der zweite Wert in der Tabelle.

Im Audit gilt: Hersteller, CNA und NVD veröffentlichen zu unterschiedlichen Zeitpunkten und können unterschiedlich bewerten. Zeigt ein Scanner Medium und ein anderer High für dieselbe Plugin-Version, ist das kein Widerspruch, den man durch die Wahl der niedrigeren Zahl auflöst. Das Audit hält die CVE-ID, den betroffenen Versionsbereich laut Record und die erste korrigierte Version fest und vergleicht diesen Bereich mit der tatsächlich installierten Version.

#WordPress-Plugins sicher über Staging aktualisieren

Der Sprung von Elementor 3.11.1 auf die Linie 3.18+ ist nicht nur ein Security-Patch. Er ändert Renderer, Widgets und oft Child-Theme-Templates. Ein Kontaktformular mit altem Upload-Shortcode kann nach dem Update einen weißen Bildschirm werfen oder Anhänge still verwerfen. Deshalb sah die Behebung nach dem Audit so aus:

• Vollständige Kopie von Dateien und Datenbank auf Staging mit derselben PHP-Version und denselben Konstanten in wp-config.php (ohne Produktions-WP_DEBUG_DISPLAY).
• Plugins mit CVEs in Triage-Reihenfolge aktualisieren, dann manueller Durchlauf: Startseite, Warenkorb oder Lead-Formular, Elementor-Editor, Formularabsendung mit Anhang.
• PHP-Logs und HTTP-500 vor dem Push auf Produktion vergleichen.
• Auf Produktion dasselbe Plugin-Versionspaar, kurzer Smoke-Test und erst danach das Entfernen überflüssiger Plugins.

Ein Update direkt auf der Live-Site ohne Backup macht aus dem CVE-Patchen einen zweiten Vorfall: toter Checkout oder kaputter Hero. Staging ist kein Agentur-Luxus. Es ist Teil des Prozesses, den auch das offizielle WordPress-Hardening auf der Wartungsebene beschreibt, nicht nur auf der Dateiebene.

#Automatische Plugin-Updates in WordPress aktivieren

Automatische Plugin-Updates gehören seit WordPress 5.5 zum Core. Die Ankündigung des Core-Teams hält fest, dass automatische Updates für Plugins und Themes standardmäßig deaktiviert sind. Es passiert also nichts, bis ein Administrator sie pro Plugin in der Plugin-Übersicht einschaltet. Beim Core ist es umgekehrt: Laut WordPress-Dokumentation zu Updates erhalten bestehende Installationen kleinere Core-Versionen, darunter Wartungs- und Sicherheitsreleases, standardmäßig automatisch.

Dieselbe Dokumentation nennt die Schalter, nach denen ein Audit in der wp-config.php und im Code suchen sollte:

• define( 'AUTOMATIC_UPDATER_DISABLED', true ); schaltet jede Art automatischer Updates ab, den Core eingeschlossen. Auf einer Site ohne manuelle Update-Routine erklärt diese eine Zeile, wie Plugins jahrelang zurückfallen.
• WP_AUTO_UPDATE_CORE mit false deaktiviert Core-Updates, 'minor' lässt nur kleinere Versionen zu, true erlaubt auch große.
• add_filter( 'auto_update_plugin', '__return_true' ); erzwingt automatische Updates für alle Plugins, und eine Callback-Funktion am selben Filter kann sie auf eine Liste von Slugs beschränken.

Auf der Kommandozeile schaltet wp plugin auto-updates enable (ab WP-CLI 2.5.0) die automatischen Updates für ein Plugin ein, mit --all für alle.

Automatische Updates ersetzen den oben beschriebenen Weg über Staging nicht. Sie passen zu kleinen Plugins mit einer einzigen Aufgabe, deren Releases die Ausgabe im Frontend selten verändern. Page Builder, Formular-Plugins und alles, was am Checkout hängt, gehören auf den Staging-Weg, weil ein Sprung über mehrere Minor-Versionen Templates verändert. Das Audit hält fest, welches Plugin in welcher Gruppe liegt, damit die Entscheidung bewusst fällt und nicht den Voreinstellungen überlassen bleibt.

#Reicht ein WAF für die WordPress-Sicherheit

Ein WAF (Cloudflare, Sucuri, Hosting-Regeln) und virtuelles Patching kaufen Zeit zwischen CVE-Enthüllung und dem Einspielen der Korrektur. Die Dokumentation der Sucuri Website Firewall beschreibt das Blockieren bekannter Anfragemuster, nicht das Entfernen verwundbaren Codes von der Platte. Diese Unterscheidung zählt im Gespräch mit einem Site-Eigentümer, der gehört hat „wir haben eine Firewall, also sind wir sicher“.

Der Patchstack-Bericht State of WordPress Security in 2026 zeigt, dass typische Hosting-plus-WAF-Setups etwa 12 Prozent bekannter WordPress-Angriffe stoppen. Der Rest umgeht Signaturen, nutzt eine eingeloggte Session, trifft einen Endpunkt außerhalb der Regeln oder greift ein Plugin an, für das es noch keine Regel gibt. Ein WAF:

• entfernt kein aufgegebenes Plugin aus wp-content/plugins/,
• repariert fehlende Nonce- und current_user_can-Prüfungen im eigenen Code nicht,
• ersetzt keinen Versionsabgleich gegen die CVE-Datenbank,
• garantiert keinen Schutz, wenn der Angriff über einen eingeloggten Redakteur läuft (wie bei CVE-2023-6449).

Sinnvoll ist WAF als erste Linie plus Update-Routine als dauerhafte Linie. Nur WAF ohne Triage und Staging lässt genau den Zustand, den wir fanden: Elementor und Formular jahrelang ohne Patch, weil „die Firewall sollte reichen“.

#Was ein WordPress-Sicherheitsaudit prüft

Ein Sicherheitsaudit ist methodisch, nicht clever. Sein Kern:

• Inventar jedes installierten Plugins und Themes und Abgleich jeder Version mit bekannten CVEs und sicherer Mindestversion. Das brachte hier die Exposition von Elementor und Contact Form 7 ans Licht.
• Triage gefundener CVEs nach Schwere, Rechten und ob die Funktion in Produktion aktiv ist.
• Test von Eigen- und Theme-Code auf WordPress-Sicherheitsgrundlagen: Nonce- und Berechtigungsprüfungen bei Aktionen, Eingaben vor der Datenbank bereinigt, Ausgaben vor der Seite escaped, Endpunkte mit Autorisierungspflicht.
• Prüfung der Server-Exposition: offene xmlrpc.php, PHP-Fehler in Produktion, die Pfade verraten, fehlende Sicherheitsheader.
• Review von Update-, Staging- und Backup-Politik, denn eine ungewartete Site treibt binnen Monaten in diesen Zustand zurück.
• Bewertung, ob der WAF die Angriffspfade der gefundenen CVEs überhaupt sieht oder nur ein Gefühl von Abdeckung liefert.

Der Versionsabgleich ist der unspektakuläre Teil, der am meisten fängt, denn die häufigste WordPress-Schwachstelle ist kein cleverer Zero-Day. Es ist ein beliebtes Plugin drei Versionen hinter seinem Patch.

#Plugin-Versionen für ein WordPress-Audit mit WP-CLI auflisten

Für die Versionsinventur braucht es zum Start keinen kostenpflichtigen Scanner. Auf einem Server mit WP-CLI zeigt wp plugin list, was installiert ist, welche Version verfügbar ist und ob automatische Updates aktiv sind:

wp plugin list --fields=name,status,version,update_version,auto_update --format=csv

Mit --status=inactive schrumpft die Liste auf deaktivierte Plugins, also Dateien, die noch auf der Platte liegen, obwohl sie niemand nutzt. Für Plugins aus dem WordPress.org-Verzeichnis zeigen die optionalen Felder wporg_status und wporg_last_updated, ob das Plugin noch gelistet ist und wann das letzte Release erschien, das schnellste Signal für ein aufgegebenes Plugin:

wp plugin list --fields=name,version,wporg_status,wporg_last_updated

Die CSV ist die Eingabe für den CVE-Abgleich: Jedes Paar aus Name und Version wird mit den betroffenen Versionsbereichen der Schwachstellendatenbank verglichen, die das Audit nutzt. Ein zweiter Befehl, wp plugin verify-checksums --all, vergleicht die Plugin-Dateien mit den von WordPress.org veröffentlichten Prüfsummen und findet Dateien, die bei einer früheren Kompromittierung verändert wurden. Er kann nur Plugins prüfen, für die WordPress.org Prüfsummen hat. Kommerzielle Plugins außerhalb des Verzeichnisses brauchen deshalb eine eigene Prüfung.

#Sicherheitsrisiken von KI-gebauten WordPress-Sites

Dieses Audit betraf veraltete Drittanbieter-Plugins, ein Vernachlässigungsmuster. KI-gestützte Deployments legen eine zweite Schicht obendrauf. Sie installieren Plugins schnell, oft ohne Update- und Staging-Routine, sodass Versionen noch schneller hinter Patches zurückbleiben. KI-generierter Eigen-Code entsteht häufig ohne die Nonce-, Berechtigungs- und Bereinigungsprüfungen, die WordPress erwartet, sodass Sie zugleich ein Problem mit veralteten Plugins und eines mit generiertem Code erben.

#Schwachstellen veralteter WordPress-Plugins beheben

Die Reihenfolge der Behebung folgt dem Risiko, nicht der Bequemlichkeit:

• Plugins mit aktiven CVEs sofort patchen oder entfernen, beginnend mit Datei-Upload- und Injection-Pfaden, nach Staging-Test.
• Aufgegebene oder nicht mehr nötige Plugins entfernen und die Fläche dauerhaft verkleinern (Dateien von der Platte, nicht nur Deaktivierung).
• Server-Exposition schließen (xmlrpc.php, Fehleranzeige in Produktion, fehlende Header).
• WAF als Zeitpuffer setzen, nicht als Ersatz für Updates.
• Eine echte Update-, Staging- und Backup-Routine einrichten, damit die Site nicht binnen eines Jahres zu fünf aktiven CVEs zurückkehrt.

Wenn Sie von einer CVE-Liste zu einem Behebungsplan auf einer Live-Site kommen müssen, starten Sie beim WordPress-Sicherheitsaudit.

#Glossar

• CVE - Bezeichner aus Common Vulnerabilities and Exposures, öffentlicher Katalogeintrag für eine bestimmte bekannte Schwachstelle.
• CVE-Triage - Sortieren von Lücken nach Schwere, Rechten und Feature-Exposition, nicht nach der Reihenfolge im Update-Bildschirm.
• SQL injection - Angriff, der Datenbankbefehle durch nicht bereinigte Eingaben einschleust.
• Stored cross-site scripting - bösartiges Skript, das auf der Site gespeichert und anderen Nutzern ausgeliefert wird.
• WAF - Web Application Firewall, die HTTP-Anfragen filtert; verengt Angriffsfenster, entfernt keinen verwundbaren Code.
• Nonce- / Berechtigungsprüfung - WordPress-Mechanismen, die bestätigen, dass eine Anfrage beabsichtigt ist und der Nutzer sie stellen darf.
• CVSS - Common Vulnerability Scoring System, der Standard von FIRST zur Bewertung des Schweregrads einer Schwachstelle von 0,0 bis 10,0.
• CNA - CVE Numbering Authority, eine vom CVE-Programm berechtigte Organisation, die CVE-IDs vergibt und CVE-Records veröffentlicht.

#Fazit

Eine WordPress-Site muss nicht interessant sein, um angegriffen zu werden. Sie muss eine bekanntermaßen verwundbare Version eines beliebten Plugins betreiben, was auf einen großen Anteil nicht auditierter Sites zutrifft. Das dominierende Risiko ist auch das langweiligste zu beheben: gleiche jede Plugin-Version mit ihren CVEs ab, triageiere, patche über Staging, vertraue nicht dem WAF allein und entferne, was Sie nicht mehr brauchen. Die Site in diesem Audit war einen Scan von Ärger entfernt und wusste es nicht. Die meisten Sites in dieser Lage wissen es nicht.