WordPress-Sicherheitsaudit

#Der Stack, den wir auditiert haben

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.

#Veraltete Plugins sind die Angriffsfläche

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 trug vier kritische CVEs (darunter SQL injection und stored cross-site scripting), während die gepatchte Linie bereits auf 3.17.3 vorgerückt war. Jedes dieser vier war in Produktion aktiv.
• Contact Form 7 5.8 war anfällig für CVE-2023-6449, eine Drag-and-drop-Datei-Upload-Schwachstelle, die einem authentifizierten Nutzer mit Redakteursrechten erlaubte, beliebige Dateien hochzuladen, ein direkter Weg zur Remote-Code-Ausführung.

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.

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.

#CVE-Triage statt Warteschlange „alles aktualisieren“

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 die Funktion aktiv ist. Ein CVE in einem Drag-and-drop-Upload-Modul betrifft nur Sites, die dieses Modul aktiv haben. Das Audit prüft, ob die Erweiterung überhaupt auf der Platte liegt.
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 stored XSS), dann Aufräumen der übrigen Plugins ohne aktives CVE. CVE-Nummer und Veröffentlichungsdatum ersetzen diese Reihenfolge nicht.

#Updates über Staging, nicht live

Der Sprung von Elementor 3.11.1 auf die Linie 3.17+ 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.

#Grenzen von WAF und virtuellem Patching

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 das Audit 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.

#Wo KI-gestützte Deployments es verschlimmern

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.

#Wie das Beheben aussieht

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 vier 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.

#Das 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.