53 Prozent aller WordPress-Seiten laufen mit ungepatchten CVEs: was das GuardingWP-Audit 2026 wirklich beweist
Mehr als die Hälfte. Der erste State of WordPress Security 2026-Bericht von GuardingWP, gezogen aus Scans von 424 bestätigten WordPress-Installationen aus mehr als vierzig Branchen, hält fest, dass 53 Prozent der Seiten mindestens ein Plugin mit bekannter ungepatchter CVE betreiben. Derselbe Bericht beziffert 93,2 Prozent ohne moderne Security-Header, 55,9 Prozent mit nach außen geleakter WordPress-Version durch das Generator-Meta-Tag und 35,8 Prozent, die XML-RPC weiterhin ausliefern.
Die Zahlen überraschen nicht. Überraschend wäre ein Befund unter dreißig Prozent, denn die Struktur der WordPress-Plugin-Ökonomie liefert diese Quote als Standardausgabe. Dieser Beitrag liest die GuardingWP-Daten als Beleg dafür, dass die Heilung keine bessere Firewall ist, sondern die Lieferketten-Kontrollen, die bereits in NIS2 Artikel 21 Absatz 2 Buchstabe d und DORA Artikel 28 geschrieben stehen, in Deutschland zusätzlich durchgesetzt durch die NIS-2-Umsetzung des Bundes und die Meldepflichten an das BSI.
Der Text steht neben unseren Pillars zu NIS2 und DORA auf WordPress: der Compliance-Stack 2026 und zur WordPress-Plugin-Lieferkette und ergänzt die Arbeit zu WCAG, BFSG und EAA, weil Einkaufsteams Barrierefreiheit, Sicherheit und Resilienz heute in einem einzigen Lieferantenbogen zusammenpacken.
Das Wichtigste in einem Absatz
- GuardingWP 2026 hat 424 bestätigte WordPress-Installationen aus mehr als 40 Branchen gescannt. Die vier Kernbefunde sind aus jeweils einer einzigen HTTP-Antwort pro Seite ablesbar.
- 53 Prozent der Seiten mit mindestens einer ungepatchten Plugin-CVE. 93,2 Prozent ohne moderne Header. 55,9 Prozent mit Versionsleck. 35,8 Prozent mit offenem XML-RPC.
- Die Quote von 53 Prozent ist keine Nachlässigkeit der Nutzer. Sie ist die Standardausgabe einer Plugin-Ökonomie mit 20 bis 40 Drittanbietern pro Installation, unkoordinierten Patch-Zyklen und dem Seitenbetreiber als Integrator letzter Instanz.
- WordPress 7.0 hat KI-Infrastruktur und damit API-Schlüssel zur Admin-Geheimnisfläche hinzugefügt. Oliver Sild von Patchstack kündigte öffentlich einen “absolute rush by hackers to steal API keys” an.
- NIS2 Artikel 21 Absatz 2 Buchstabe d und DORA Artikel 28 kodieren die Heilung bereits: dokumentierte Schwachstellenrichtlinie, Patch-Kadenz, Lieferantenbewertung, Register der IKT-Drittparteienverträge.
- Der Hebel, der eine WordPress-Organisation von Compliance-Versagen zu Compliance-Bestehen bewegt, ist kein Plugin. Es ist ein Kontrollrahmenwerk.
Die Zahlen, mit Quelle
Die vier Kernkennzahlen des GuardingWP-Berichts 2026 sind von außerhalb der Seite beobachtbar. Ein Scanner braucht nur die Antwort der Startseite und den HTTP-Status auf /xmlrpc.php, um jede einzelne abzuleiten. Das ist wichtig, weil Compliance-Auditoren zunehmend zuerst externe Evidenz heranziehen, und die Telemetrie von Patchstack, GreyNoise und das Internet Archive stehen als dauerhafte Messinfrastruktur bereit.
| Befund | Anteil an 424 Installationen |
|---|---|
| Mindestens ein Plugin mit bekannter ungepatchter CVE | 53 Prozent |
| Ohne moderne Header (CSP, HSTS, X-Content-Type, Referrer-Policy) | 93,2 Prozent |
| Leck der WordPress-Version über Generator-Meta-Tag | 55,9 Prozent |
| Offener XML-RPC-Endpunkt | 35,8 Prozent |
Für die EU-regulierte Leserschaft hat jede dieser vier Zahlen einen anderen Bezugsrahmen. CSP und HSTS sind in den ENISA-Empfehlungen für die Sicherheit internetzugewandter Systeme genannt. Die XML-RPC-Exposition steht ausdrücklich in den OWASP Top 10. Ungepatchte Plugin-CVEs mappen direkt auf NIS2 Artikel 21 zur Lieferkettensicherheit. Der GuardingWP-Bericht ist keine Kuriositätenliste. Er ist eine Messung von vier bereits kodifizierten Compliance-Lücken.
Warum 53 Prozent eine strukturelle Zahl ist
Eine typische WordPress-Seite betreibt zwischen zwanzig und vierzig Plugins. WordPress.org veröffentlicht mehr als 60 000 Plugins, mit einem langen Schwanz von Autoren ohne finanziertes Sicherheitsteam. Der Patch-Zyklus von Plugin A und Plugin B ist nicht koordiniert. Der Seitenbetreiber ist der Integrator letzter Instanz. Wenn CVE-2025-XYZW am Dienstag in Plugin A landet, ist der Seitenbetreiber die einzige Partei, die entscheiden kann, ob gepatcht wird, ob gegen den Rest des Stacks getestet wird und ob der Patch Plugin B kaputtmacht.
Die Ökonomie der Lage begünstigt den Integrator nicht. Zwanzig Plugins pro Monat mit Regressionstests zu patchen ist Ingenieurarbeit. Die meisten WordPress-Seiten haben kein Budget für diese Arbeit. Deshalb werden die meisten WordPress-Seiten nicht gepatcht. Die Quote von 53 Prozent ist das Marktgleichgewicht.
Es gibt zwei Wege aus dieser Gleichgewichtslage, und nur einer ist tragfähig.
Der erste Weg ist die Schrumpfung des Plugin-Stacks. Eine WordPress-Seite mit acht Plugins, alle aktiv gewartet, alle individuell auf eine Funktion zugeschnitten, die der Betreiber in einem Satz beschreiben kann, ist eine handhabbare Patch-Oberfläche. Die Disziplin kostet oben mehr, weil das Team die Funktion entweder in Custom-Code bauen oder ohne sie leben muss, aber die monatlichen Kosten zur Aufrechterhaltung des Patch-Status sinken proportional.
Der zweite Weg ist das Outsourcing der Patch-Kadenz an einen Managed Provider, der das tatsächlich macht. Genau das liefern ernsthafte Managed-WordPress-Hoster und ernsthafte Agenturen aus, und dort, wo der Vertrag ausdrücklich sagt: “wir spielen Security-Patches innerhalb von X Stunden nach Vendor-Release ein, zuerst auf Staging, dann Produktion”. Steht das nicht im Vertrag, existiert die Kadenz nicht, und die Seite ist statistisch in den 53 Prozent.
Was WordPress 7.0 verändert hat
WordPress 7.0 “Armstrong” ist in derselben Veröffentlichungswoche wie der GuardingWP-Bericht erschienen. Das 7.0-Release brachte die AI Services Registry und die Abilities API mit. Das heißt, die Admin-Oberfläche hält jetzt API-Schlüssel für gehostete Modellanbieter (Anthropic, OpenAI), KI-Gateways (Vercel) und selbst gehostete Endpunkte. Diese Schlüssel haben eine Kostenseite. Ein kompromittierter Admin-Zugang ist nicht mehr nur ein Problem der Inhaltsintegrität. Er ist auch ein Problem des Kostenlecks.
Patchstack-Gründer Oliver Sild schrieb am Tag der 7.0-Veröffentlichung öffentlich auf X: “there will be an absolute rush by hackers to steal API keys.”
Justin Nealey hat in seinem Blog das verwandte praktische Kopfweh markiert: Der WP AI Client hat keinen eingebauten Throttle, und mehrere Plugins, die sich einen API-Schlüssel teilen, können das Token-Limit in weniger als einer Minute leerblasen. Das ist kein hypothetischer Angreifer, das ist eine wohlmeinende Fehlkonfiguration. Beide Formen des Kostenlecks verlangen dieselbe Kontrolle: Schlüssel-Scoping pro Connector, Rate-Limits am Gateway statt im Plugin, ein Audit-Log, das unerwarteten Token-Verbrauch innerhalb eines Abrechnungszyklus sichtbar macht.
Die Kontrolloberfläche ist gut verstanden. Es ist dieselbe, die ein Finanzteam auf jede neu geprägte abrechenbare Anmeldeinformation anwenden würde. WordPress ist nur insofern ungewöhnlich, als es diese Klasse von Anmeldedaten historisch nicht im Admin hatte.
Wie NIS2 die GuardingWP-Daten liest
Die NIS2-Richtlinie (2022/2555), Artikel 21, Absatz 2, listet zehn technische und organisatorische Maßnahmen auf, die wesentliche und wichtige Einrichtungen anwenden müssen. Absatz 2 Buchstabe d verlangt mit den Worten der Richtlinie selbst die “Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen jeder Einrichtung und ihren unmittelbaren Anbietern oder Diensteanbietern”. Eine WordPress-Installation mit ungepatchten Plugin-CVEs verfehlt Buchstabe d unabhängig davon, ob das einzelne Plugin kritisch ist, weil die Einrichtung das Lieferantenrisiko nicht bewertet und gesteuert hat.
Die Heilung unter NIS2 ist prozedural. Sie umfasst:
- Eine dokumentierte Richtlinie zur Schwachstellenbehandlung und -offenlegung, an die sich die Einrichtung tatsächlich hält. Absatz 2 Buchstabe b.
- Eine Patch- und Update-Kadenz mit einem Zielwert für die Anwendung CVE-bewerteter Fixes. Absatz 2 Buchstabe f in Verbindung mit Buchstabe b.
- Eine Lieferantenbewertung, die die Plugin-Autoren als IKT-Drittanbieter einschließt, mit deren Sicherheitsreife, Offenlegungskanal und Patch-Latenz. Absatz 2 Buchstabe d.
- Ein Register der IKT-Drittparteienverträge, das unter DORA für Finanzunternehmen aus Artikel 28 zusätzlich verpflichtend wird.
Eine WordPress-Seite kann die technische Lesart von NIS2 bestehen (also am Audit-Tag keine ungepatchten CVEs aufweisen) und auf der prozeduralen Lesart trotzdem scheitern, wenn die Einrichtung die Dokumente nicht vorzeigen kann. Die 53-Prozent-Quote legt nahe, dass die Dokumente für die Hälfte der in den Anwendungsbereich fallenden Seiten nicht existieren.
In Deutschland setzt das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz die Richtlinie um, und das Bundesamt für Sicherheit in der Informationstechnik (BSI) bündelt die zentrale Meldestelle für Vorfälle. Wesentliche und wichtige Einrichtungen im KRITIS-Sektor müssen erhebliche Vorfälle dort melden, und das Fehlen einer dokumentierten Schwachstellenrichtlinie und Patch-Kadenz im Plugin-Portfolio lässt sich in einer BSI-Prüfung schwer verteidigen. Wer in einem regulierten Sektor sitzt, hat damit nicht nur ein Betriebsrisiko, sondern ein klares Regulierungsrisiko, sobald das GuardingWP-Profil auf den Tisch kommt.
Das ist der Teil der Diskussion, dem die meisten Security-Tool-Anbieter ausweichen. Eine Firewall zu verkaufen ist einfacher als ein Kontrollrahmenwerk zu verkaufen. Das Kontrollrahmenwerk ist, was NIS2 tatsächlich verlangt.
Wie DORA die GuardingWP-Daten für Finanzunternehmen liest
Die DORA-Verordnung (2022/2554) ist seit dem 17. Januar 2025 unmittelbar anwendbar. Sie gilt für Kreditinstitute, Zahlungsinstitute, Versicherer, Wertpapierfirmen, Anbieter von Kryptodiensten und rund fünfzehn weitere in Artikel 2 aufgeführte Kategorien. Für deutsche Finanzunternehmen führt die BaFin die Aufsicht.
DORA Artikel 28 regelt das Management des IKT-Drittparteienrisikos. Die Plugin-Autoren der öffentlichen Website eines Finanzunternehmens fallen unter diese Definition. Zwei praktische Folgen ergeben sich aus dem GuardingWP-Profil.
Erstens muss die Einrichtung ein Register vertraglicher Vereinbarungen mit IKT-Drittanbietern führen (Artikel 28 Absatz 3). Dieses Register muss die Plugin-Herausgeber abdecken, deren Code auf der öffentlichen Seite läuft. Bei den meisten Finanzunternehmen enthält dieses Register WordPress-Plugin-Autoren derzeit überhaupt nicht. Die Heilung ist nicht technisch, sie ist administrativ: die aktive Plugin-Liste extrahieren, jedes Plugin seinem Herausgeber zuordnen, den Schwachstellenkanal und die Patch-Latenz des Herausgebers anhängen und den Eintrag ins Register aufnehmen.
Zweitens verlangt Artikel 28 Absatz 5, dass vertragliche Vereinbarungen mit IKT-Drittanbietern, die kritische oder wichtige Funktionen erbringen, “Ausstiegsstrategien einschließen, insbesondere die Festlegung einer obligatorischen angemessenen Übergangsfrist”. Für eine WordPress-Seite, die für einen kritischen Workflow von einem einzigen spezialisierten Plugin abhängt (Zustellung signierter Dokumente, KYC-Adapter, Zusammenstellung regulatorischer Berichts-PDFs), muss die Ausstiegsstrategie schriftlich existieren. Sie existiert selten.
Das sind keine glamourösen Kontrollen. Es ist Papier. Es ist auch, wie ein tatsächliches DORA-Audit aussieht.
Wo der GuardingWP-Bericht zu leise ist
Die Kernzahlen des Berichts sind gut belegt, aber er unterspielt eine Sache, die der Praktiker sehen muss: Die Quote von 53 Prozent konzentriert sich im langen Schwanz kleiner Geschäftsinstallationen und ist deutlich niedriger bei Installationen mit einem Managed Provider auf einem Vertrag, der ausdrücklich Security-Patching abdeckt. Wir haben die zugrunde liegende Segmentierung von GuardingWP nicht, aber unsere eigene Konzentration von WordPress-Seiten unter Wartungsvertrag liegt für die ungepatchte CVE-Quote in einer beliebigen Auditwoche im einstelligen Bereich.
Die Implikation ist nicht, dass Managed-WordPress-Hoster und security-fokussierte Agenturen perfekt sind. Sie ist, dass die Gleichgewichtsquote von 53 Prozent ein Marktdurchschnitt ist, der zwei sehr unterschiedliche Populationen mischt. Ein Käufer, der den Bericht liest, sollte nicht zu dem Schluss kommen “WordPress ist unsicher”. Er sollte zu dem Schluss kommen: “WordPress-Seiten ohne Kontrollrahmenwerk sind unsicher, und die Größe des unbetreuten Schwanzes beträgt die Hälfte des Marktes”.
Was sich ändert, wenn WordPress 7.0 ernst genommen wird
Die Veröffentlichung von WordPress 7.0 mit KI-Infrastruktur ist eine nützliche erzwingende Funktion für den unbetreuten Schwanz, weil das Hinzufügen von API-Schlüsseln zur Admin-Oberfläche den Kostenleck-Fall in einer Weise sichtbar macht, wie es XSS oder die Exfiltration gespeicherter Anmeldedaten nie waren. Eine Person aus der Finanzabteilung, die von “Sie könnten eine ungepatchte CVE haben” nicht bewegt wurde, lässt sich von “Ihre KI-Anbieter-Rechnung des letzten Monats lag dreistellig über dem Üblichen und wir können den Traffic nicht erklären” bewegen.
Die Kontrolloberfläche, die das KI-Schlüssel-Risiko schließt, schließt auch viel vom Rest der GuardingWP-Befunde, weil sich die Kontrollen überlappen:
- Moderne Security-Header (CSP, HSTS, X-Content-Type, Referrer-Policy) am Edge. Ein Cloudflare Worker oder ein
.htaccess-Block. Schließt die Lücke von 93,2 Prozent. - Unterdrückung des Generator-Meta-Tags. Ein Filter. Schließt die Lücke von 55,9 Prozent.
- XML-RPC abgeschaltet oder am Edge ratenbegrenzt. Eine Firewall-Regel oder eine
.htaccess-Zeile. Schließt die Lücke von 35,8 Prozent. - API-Schlüssel-Scoping, Rate-Limit pro Connector, Anomalie-Alerts auf Token-Verbrauch. Neue Kontrolloberfläche. Schließt das 7.0-Risiko, bevor es Skalierung hat.
Das sind keine heroischen Ingenieuraufgaben. Das sind Posten im Leistungsverzeichnis eines Managed-Services-Vertrags.
Eine Praktiker-Lesart
Ich führe seit fünfzehn Jahren Sicherheitsaudits für WordPress-Seiten unter EU-Rechtsordnungen durch. Das wiederkehrende Muster im Jahr 2026 ist dasselbe wie 2018: eine Seite kommt mit achtundzwanzig Plugins, der Betreiber kann nicht aufzählen, was acht davon tun, und der Regressionstest-Aufwand, alles in einem Zyklus zu patchen, übersteigt das Budget. Die GuardingWP-Quote ist eine getreue Beschreibung dieses Musters. Die Heilung, die auf einem Jahreshorizont tatsächlich wirkt, ist die, die niemand mag:
- Audit der Plugin-Liste. Entfernen Sie jedes Plugin, dessen Funktion der Betreiber nicht in einem Satz beschreiben kann.
- Ersetzen Sie die zwei oder drei Plugins, die überleben, aber stagnierende Wartungskanäle haben.
- Etablieren Sie eine dokumentierte Patch-Kadenz und eine Schwachstellenrichtlinie. Schreiben Sie es auf. Verweisen Sie im Wartungsvertrag namentlich darauf.
- Fügen Sie ein Register der IKT-Drittparteienverträge hinzu, das die aktive Plugin-Liste abbildet und bei jedem Plugin-Add oder -Remove aktualisiert wird.
- Für WordPress 7.0-Installationen: scopen Sie jeden KI-Anbieter-Schlüssel pro Connector, wenden Sie Rate-Limits am Gateway an und alarmieren Sie auf Anomalien beim Token-Verbrauch.
Die ersten vier Punkte sind Compliance-Arbeit unter NIS2 Artikel 21. Der fünfte ist die neue Kontrollklasse, die 7.0 einführt. Keiner der fünf wird als Produkt von einem Anbieter gekauft. So erscheint ein WordPress-Praktiker zur Arbeit.
Schlussargument
Der GuardingWP-Bericht 2026 ist das nützlichste Einzeldokument, das die WordPress-Sicherheitscommunity in fünf Jahren veröffentlicht hat, weil er eine Debatte umformuliert, die zu lange im Tool-Vergleichsmodus festsaß. Die richtige Lesart ist nicht “wechseln Sie zu Patchstack” oder “installieren Sie Wordfence”. Sie lautet: die Hälfte des Marktes betreibt kein Kontrollrahmenwerk, die Kontrollen, die die Lücke schließen, sind in NIS2 und DORA kodifiziert, und der Käufer am Empfängerende der EU-Regulierung 2026 ist derjenige mit dem Hebel, die Kontrollen in den Lieferantenvertrag zu zwingen.
Für den Leser aus der WordPress-Agentur ist dies seit Jahren der stärkste kommerzielle Moment, das Rahmenwerk zu verkaufen, nicht das Werkzeug. Die Zahl 53 Prozent ist der Aufmacher des nächsten Lieferantenpitchs.
Quellen
- GuardingWP, State of WordPress Security 2026 (Berichtsseite)
- Richtlinie (EU) 2022/2555 zur Sicherheit von Netz- und Informationssystemen (NIS2), Artikel 21
- Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor (DORA), Artikel 28
- Patchstack
- ENISA: Empfehlungen zur Sicherheit internetzugewandter Systeme
- BSI: Bundesamt für Sicherheit in der Informationstechnik
- BaFin: Bundesanstalt für Finanzdienstleistungsaufsicht
- OWASP Top 10 2021
Verwandte Beiträge bei uns
- Pillar: NIS2 und DORA auf WordPress: der Compliance-Stack 2026
- WordPress-Plugin-Lieferkette 2026: vier Backdoors in einem Monat
- WCAG 2.2, BFSG und EU Accessibility Act: der Compliance-Stack 2026 für WordPress
- WordPress-Sicherheitsaudit
- DORA Artikel 28 IKT-Drittparteienrisiko: WordPress-Hosting- und WAF-Lieferantenaudit
Zuletzt aktualisiert: 2026-05-23
