WordPress bekam 773 Sicherheitsmeldungen in einem Monat. Das liest niemand.

Ich betreue immer noch WordPress-Seiten für vier Kunden. Nicht weil ich WordPress liebe. Sondern weil diese Seiten laufen, die Kunden zufrieden sind, und etwas Funktionierendes rauszureißen, nur um recht zu behalten, ist eine schlechte Art, eine Agentur zu führen.

Als ich also gelesen habe, dass das WordPress-Security-Team im August 773 Vulnerability-Reports bekommen hat, war mein erster Gedanke nicht "WordPress ist am Ende." Sondern: Wer soll das lesen?

Die Antwort ist eine kleine Gruppe, überwiegend Freiwillige. Und die Zahl, die sie früher bekommen haben, lag bei 20 bis 30 im Monat. Etwa ein Jahrzehnt lang.

Diese Lücke ist die ganze Geschichte der WordPress Core Security im Moment, und es ist nicht die Geschichte, die die Schlagzeile nahelegt.

773 Meldungen in einem Monat. Die Zehn-Jahres-Basis lag bei 20.

Hier die tatsächlichen Zahlen, aus dem Bericht von The Repository: Der Juli war schon ein Rekord mit rund 450 Meldungen. Der August schloss bei 773. Die historische Basis, rund zehn Jahre zurück, lag bei 20 bis 30 im Monat.

Das ist keine Trendlinie. Das ist eine Wand.

John Blackbourn aus dem WordPress-Security-Team schrieb, dass "unmanageable numbers of low severity reports" die Änderung der Scope erzwungen haben, und dass der Anstieg im Januar und Februar begann, hauptsächlich getrieben von GPT 5.3 und Claude Opus 4.6. Seine Worte, nicht meine: "We're well into an entirely new era of AI-assisted security research."

Ich will hier vorsichtig sein, denn die einfache Geschichte lautet "AI-Slop überschwemmt WordPress und die Maintainer ersaufen." Das stimmt zur Hälfte, und die Hälfte, die nicht stimmt, ist die wichtige.

Niemand bei WordPress hat einen Slop-Prozentsatz veröffentlicht. Veröffentlicht wurde, dass die Meldungen low severity sind, nicht dass sie erfunden sind. Das sind zwei verschiedene Probleme. Ein Stapel von 700 echten, aber trivialen Funden ist auf eine Weise zermürbend, wie es 700 Halluzinationen nicht sind, denn du kannst keine davon abtun, ohne sie vorher gelesen zu haben. Das ist der eigentliche Flaschenhals: Triage-Kapazität, nicht Müllerkennung.

curl ist zuerst gegen diese Wand gelaufen, und wir haben deren Zahlen

WordPress hat keine Validitätsrate veröffentlicht. curl schon, und curls Erfahrung ist das Nächste, was wir an einer Kontrollgruppe haben.

Daniel Stenberg berichtete, dass rund 20% der eingehenden Meldungen bei curl AI-generiert waren, und dass in einem Jahr nur etwa 5% der gemeldeten Schwachstellen echt waren. Sein Lieblingsbeispiel: ein detaillierter HTTP/3-"Stream Dependency Cycle Exploit", inklusive GDB-Sessions und Register-Dumps, der sich auf eine Funktion bezieht, die es nirgendwo in curl gibt.

Am 1. Februar 2026 hat curl seine Bug Bounty auf HackerOne komplett dichtgemacht. Einen Monat später, im März, kam sie zurück. Lies die Reihenfolge nochmal, denn sie ist das Ehrlichste an dieser ganzen Geschichte. Die Maintainer sind gegen eine Wand gelaufen, haben die drastische Option gezogen, und dann festgestellt, dass die drastische Option schlimmer war als die Wand.

Genau da steht WordPress jetzt, nur ohne die Abschaltung. Gleicher Druck, größere Angriffsfläche, mehr Freiwillige, und rund 40% des Webs hängen an der Entscheidung dran.

Was die Scope-Änderung bei WordPress Core Security wirklich sagt

Die Änderung ist zwei Sätze lang und sie lautet nicht "wir lehnen AI-Meldungen ab."

Aus den aktualisierten Disclosure-Richtlinien: Für jedes In-Scope-Asset außer WordPress Core und Gutenberg sind Issues, die eine Rolle voraussetzen, die nur ein Administrator vergeben kann, in der Regel nicht mehr berechtigt, es sei denn, sie zeigen eine Eskalation mit hoher Severity. Und getrennt davon: Dass eine authentifizierte Rolle eine Aktion ausführen kann, die normalerweise einer anderen authentifizierten Rolle vorbehalten ist, reicht allein nicht mehr aus, solange es nicht zu einer Eskalation mit hoher Auswirkung führt.

Übersetzt: Wenn du einen Contributor-Account brauchst, den dir erst ein Admin geben muss, damit dein Exploit funktioniert, ist das meistens kein Bounty-Fall mehr. Für Core und Gutenberg gelten die alten Regeln vorerst weiter.

Das ist ein Triage-Filter, kein Sicherheitsrückzug. Es schneidet die Klasse von Meldungen weg, die einen Freiwilligen vierzig Minuten Reproduktion kostet und mit "ein Account, den du absichtlich angelegt hast, kann etwas leicht Falsches tun" endet. Ich habe vor Jahren selbst Dinge aus dieser Kategorie eingereicht, und ich möchte nicht der Mensch sein, der 773 davon liest.

Parallel dazu hat WordPress im August eine Core Security Initiative gestartet, mit drei erklärten Säulen: ein besserer Release-Prozess mit verbessertem Testing, den Melde-Backlog abbauen, indem man Leute dazuholt, und AI-gestütztes Scanning nutzen, um Schwachstellen proaktiv zu finden. Der letzte Punkt hat mich kurz schmunzeln lassen. Das Mengenproblem ist AI-gestützte Security-Forschung, und die Antwort enthält mehr AI-gestützte Security-Forschung, nur nach innen gerichtet. Es könnte tatsächlich funktionieren. Es ist auch der einzige Hebel, den sie haben, der ohne Einstellungen skaliert.

Die Zahl, die dir Sorgen machen sollte, ist nicht 773

Hier kommt das, was für die Seite zählt, die dir gehört, und es hat fast nichts mit der Bug-Bounty-Queue zu tun.

Der Patchstack-Report 2026 zählt 11.334 neue WordPress-Schwachstellen im Jahr 2025, ein Plus von 42% gegenüber dem Vorjahr. Von den neuen Schwachstellen steckten 91% in Plugins und 9% in Themes. Sechs waren in WordPress Core, alle mit niedriger Priorität.

Sechs. Im Core. Von 11.334.

WordPress Core Security ist nach diesen Zahlen in ordentlicher Verfassung. Das Gebäude steht. Es sind die Anbauten, die lecken, und davon gibt es 60.000 im offiziellen Verzeichnis, bei den meisten ohne irgendein Security-Team dahinter.

Zwei weitere Zahlen aus demselben Report, an die ich öfter denke als an die 773:

• 46% der Schwachstellen waren zum Zeitpunkt der Disclosure nicht rechtzeitig gepatcht. Fast die Hälfte ging an die Öffentlichkeit, während das Plugin noch kaputt war.
• Bei den stark ausgenutzten Schwachstellen wurden 20% innerhalb von sechs Stunden nach Disclosure ausgenutzt, 45% innerhalb von 24 Stunden, 70% innerhalb einer Woche. Der gewichtete Median bis zur ersten Ausnutzung lag bei fünf Stunden.

Fünf Stunden. Das ist dein Patch-Fenster, und es startet, während du schläfst. Ich habe schon darüber geschrieben, wie Angreifer Bugs inzwischen schneller finden, als Teams patchen können, und das hier ist dieselbe Geschichte von der Maintainer-Seite des Schreibtischs aus. Gleiche Beschleunigung, nur hat die eine Gruppe Bounty-Anreize und unbegrenzte Rechenleistung, die andere hat Freiwillige und einen Dienstagabend.

Was ich für die WordPress-Seiten tue, die ich noch betreue

Nichts auf dieser Liste ist clever. Das ist der Punkt.

Auto-Updates sind für den Core an, immer, auch für Minor Releases. Als ein Kunde mich bat, sie abzuschalten, nachdem ein Plugin-Konflikt ein Layout zerschossen hatte, habe ich nein gesagt und angeboten, stattdessen das Plugin zu reparieren. Das hat zwei Stunden gekostet und eine Diskussion erspart, die ich schon oft geführt habe.

Die Anzahl der Plugins ist der eigentliche Hebel. Ein Kunde kam mit 34 aktiven Plugins zu mir. Wir sind bei 11. Neun der entfernten machten etwas, das ein Dutzend Zeilen Theme-Code auch können, vier waren verwaist, und zwei waren Dubletten voneinander, weil zwei verschiedene Agenturen ihre jeweilige Lieblingsvariante installiert hatten. Jedes Plugin, das du löschst, ist eine Schwachstelle, die du nie um 3 Uhr nachts patchen musst.

Ich schaue auf den Wartungsstand, nicht auf Sternebewertungen. Datum des letzten Commits, Anzahl offener Issues, ob der Maintainer antwortet. Ein Fünf-Sterne-Plugin mit 400.000 Installationen und seit 18 Monaten ohne Commit ist schlechter als ein Zwei-Sterne-Plugin von jemandem, der jeden Monat ausliefert.

Und ich habe aufgehört zu glauben, dass ein Security-Plugin eine Seite sicher macht. Ich habe einen ganzen Beitrag darüber geschrieben, welche WordPress-Security-Plugins wirklich einen Platz verdienen, und die ehrliche Kurzfassung ist: Sie kaufen dir Monitoring und eine Firewall, keine Immunität. Was tatsächlich etwas bewegt, ist langweilig: weniger Plugins, echte Updates, Benutzerrollen mit minimalen Rechten, Offsite-Backups, aus denen du wenigstens einmal wirklich zurückgespielt hast. Das ist der Großteil meiner Checkliste zur Website-Sicherheitshärtung und nichts davon braucht ein Abo.

Für neue Kundenprojekte fange ich inzwischen meist gar nicht mehr mit WordPress an, und ich habe ehrlich aufgeschrieben, wie ich zwischen WordPress, Next.js und Astro entscheide. Aber "ich würde es heute anders bauen" ist kein Grund, einem bestehenden Kunden zu sagen, seine funktionierende Seite sei eine Belastung. Meistens ist sie das nicht.

Der Teil, für den ich keine Antwort habe

Die 773 gehen nicht wieder runter. Egal, was WordPress mit der Scope macht, das Frontier-Modell des nächsten Jahres wird besser PHP lesen als das dieses Jahres, und die Kosten, es auf eine Codebasis loszulassen, fallen weiter Richtung null.

Also wächst die Queue, und die einzigen Dinge, die mit WordPress Core Security mitskalieren, sind Automatisierung und Geld. WordPress hat beides nicht in der Menge, die das hier braucht. Es hat ein Security-Team aus Freiwilligen und eine Foundation, und darunter hängt ein beachtlicher Teil des Webs.

Ich weiß nicht, wie das ausgeht. Die optimistische Version: AI-gestütztes Scanning auf der Verteidigungsseite holt auf, der Backlog löst sich auf, und in zwei Jahren liest sich das hier wie ein Wachstumsschmerz. Die pessimistische Version: Triage-Kapazität wird zum dauerhaften Flaschenhals in der Open-Source-Sicherheit, und die Projekte, die das überleben, sind die, bei denen eine Firma dafür bezahlt, dass Menschen Meldungen lesen.

curl hat aufgehört und kam einen Monat später zurück. Ich lese das so, dass ein Maintainer festgestellt hat: Es gibt keinen Ausgang, nur eine Warteschlange. Ich wäre gern im Unrecht damit.

Wenn du WordPress betreibst und das hier dich dazu gebracht hat, dir deine Plugin-Liste wirklich anzusehen, statt nur ein diffuses Unwohlsein zu spüren, dann ist das die richtige Reaktion. Ich kann dir keine Seite versprechen, die nie eine Schwachstelle hat, denn diese Seite gibt es nicht. Was ich anbieten kann, ist ein Blick darauf, was tatsächlich installiert ist, was verwaist ist und was weg kann. Lass uns reden, wenn das nützlich klingt.