KI überschwemmt WordPress mit Schwachstellenmeldungen. Wer zahlt für die Patches?

In 90 Tagen erhielt das WordPress-Sicherheitsprogramm 2004 Schwachstellenmeldungen und zahlte dafür über 90.000 Dollar aus. Das ist fast die Hälfte aller Auszahlungen seit 2017. Bisher zahlte dafür ein einziger Akteur: Automattic. Am Montag, dem 5. Oktober 2026, schrieb Mary Hubbard, Executive Director von WordPress, an die Chefs von mehr als 30 Firmen mit der Bitte, sich zu beteiligen.

Ich stütze mich auf den Artikel von The Repository vom 8. Oktober 2026, der Hubbards Mail zitiert (The Repository, 8. Oktober 2026), sowie auf die Ankündigungen auf wordpress.org. Die Mail selbst habe ich nicht gesehen. Zahlen und Zitate habe ich am 9. Oktober 2026 an den Quellen geprüft.

#Worum Mary Hubbard Hoster und Plugin-Firmen bittet

Die Mail ging am Abend (UTC) an die Chefs von Hosting-, Plugin- und Sicherheitsfirmen. The Repository schreibt von “Montagabend UTC” (eigene Übersetzung) in einem Text vom Donnerstag, dem 8. Oktober. Die Kernthese: KI hat die Suche nach Lücken billig gemacht.

“KI hatte die Kosten für das Finden, Melden und Ausnutzen von Schwachstellen einbrechen lassen”

Mary Hubbard, zitiert von The Repository, 8. Oktober 2026, eigene Übersetzung

Laut Hubbard erhielt das Programm in 90 Tagen fast 2000 Meldungen, so viele wie nie zuvor, “und das Tempo steigt weiter” (eigene Übersetzung). The Repository prüfte die HackerOne-Seite des Programms: 2004 Meldungen und über 90.000 Dollar Prämien in 90 Tagen, bei knapp über 200.000 Dollar Gesamtauszahlungen seit dem Start im April 2017.

“Fast die Hälfte aller Auszahlungen seit Bestehen des Programms fiel in ein einziges Quartal, und die Kurve geht nur in eine Richtung.”

Mary Hubbard, zitiert von The Repository, 8. Oktober 2026, eigene Übersetzung

Hubbard schreibt außerdem, Automattic habe das Programm zu 100 % finanziert: jede Prämie, Triage, Verifizierung, Fixes und koordinierte Sicherheitsreleases für alle unterstützten Zweige bis hinunter zu WordPress 4.7. Sie bittet um eines von drei Dingen: einen Beitrag zu einem gemeinsamen Prämientopf, die Finanzierung von Personal für Triage und Releases oder eine andere, gemeinsam vereinbarte Form. Sie betont, dass ein Teil des Anstiegs echte Forschung sei, die dank neuer Werkzeuge schneller vorankommt und die Sicherheit tatsächlich verbessert. Das Problem sei die Ökonomie, nicht das Programm selbst: “Kaputt ist die Ökonomie, nicht das Programm” (eigene Übersetzung).

#Welche Firmen um Geld für die WordPress-Sicherheit gebeten wurden

An der Spitze der Empfängerliste standen GoDaddy, Newfold Digital und Hostinger. The Repository nennt weiter:

Quelle: The Repository, 8. Oktober 2026.

Die Mail erhielt nicht WP Engine, das seit 2024 mit Automattic vor Gericht streitet, obwohl Vertreter von WP Engine in den Danksagungen der Sicherheitsreleases 7.0.2 und 7.1.1 genannt wurden. Auch Nexcess stand nicht auf der Liste.

#Wie Hoster und Plugin-Firmen reagierten

Wer The Repository antwortete, ist grundsätzlich dafür, will aber genau wissen, worauf er sich einlässt.

• Hostinger (Marco Chiesi): erwägt, eigene Leute abzustellen. Seit Juli arbeitet das Unternehmen mit dem Sicherheitsteam zusammen und rollt WAF-Regeln aus, bevor Patches erscheinen.
• Kinsta (Jon Penland): wünscht ein “klar definiertes” (eigene Übersetzung) Programm, zu dem Firmen beitragen könnten.
• Awesome Motive (Syed Balkhi): sponsert bereits mehrere Mitwirkende der Sicherheits- und Plugin-Teams, merkt aber an, die Bitte sei “ziemlich offen gehalten” (eigene Übersetzung).
• Human Made (Tom Willmot): sponsert John Blackbourn, der in Vollzeit das Sicherheitsteam vertritt. Die Agentur hatte früher versucht, Firmen um einen Sicherheitsfonds zu versammeln, “leider ohne große Resonanz” (eigene Übersetzung).
• Patchstack (Oliver Sild): Die Firma hat seit 2022 aus eigener Tasche 600.000 Dollar an Prämien gezahlt, wurde aber nie in die Sicherheits- und Plugin-Teams von WordPress aufgenommen. Seiner Ansicht nach “muss dieser Prozess reformiert werden” (eigene Übersetzung).

GoDaddy, Newfold Digital und Wordfence hatten bis zur Veröffentlichung des Textes nicht geantwortet.

#WordPress 7.1.4: 22 Schwachstellen und was das für Ihre Website bedeutet

Aktualisierung, 30. Oktober 2026. WordPress 7.1.4 erschien am 28. Oktober. Die Versionsseite zählt 22 Schwachstellen. Die schwerste ist eine Race Condition im Update-Prozess des Kerns, die laut dem Melder Umut Bayram zu Remote Code Execution führen konnte. Die meisten übrigen sind Stored-XSS-Lücken, für die mindestens ein Mitarbeiter-Konto nötig ist. Zwei Meldungen werden Anthropic zugeschrieben. Die Korrekturen wurden auf ältere Zweige zurückportiert, von 7.0.8 bis 4.7.39, und Websites mit automatischen Hintergrund-Updates erhalten den Patch selbstständig.

Es ist das siebte Sicherheitsrelease des Kerns seit Juli. Im Zwischenstand nach zwei Monaten Core Security Initiative schreibt Rudy Faile, dass das Team in diesem Jahr mehr als 3.000 Meldungen erhalten hat, mehr als in den zwölf Jahren davor zusammen, und dass 73 % der 109 Schritte eines Sicherheitsreleases inzwischen automatisiert sind. Bei diesem Tempo ist es keine sichere Gewohnheit mehr, ein Sicherheitsupdate aufs Wochenende zu schieben. In meinem Update-Service für WordPress gehen Sicherheitsreleases zuerst auf Staging und dann in die Produktion.

#Was WordPress 7.1.3 behebt und wer die Lücken meldete

Einen Tag nach der Mail, am 6. Oktober 2026, erschien WordPress 7.1.3 mit 7 Sicherheitsfixes und 4 weiteren Fehlerbehebungen. Die Ankündigung nennt bei jedem Fix, wer ihn gemeldet hat:

Quellen: Melder laut WordPress.org, 6. Oktober 2026, Ausnutzungsbedingungen laut Patchstack, 6. Oktober 2026.

Nur eine der sieben Lücken funktioniert ohne jedes Konto und ohne Zutun des Opfers: der Kommentarabfluss aus privaten Beiträgen. Patchstack erklärt den Mechanismus: Im Kommentar-Feed eines einzelnen Beitrags holte WordPress zuerst die Kommentare und prüfte erst danach, ob der Besucher den Beitrag sehen darf. Die Prüfung versteckte den Beitrag, aber nicht die Kommentare, und Feeds liefern kein 404, also gelangten die Kommentare in den Feed. Drei der übrigen sechs setzen ein Konto als Mitarbeiter oder Autor voraus.

Vier der sieben Meldungen stammen von Firmen, die KI-Modelle bauen, oder von deren Partnern. Das illustriert Hubbards These gut: Lücken findet heute auch KI, und für jede muss jemand mit Triage, Fix und einem Release für jeden unterstützten Zweig bezahlen. In der Ankündigung heißt es, die Fixes würden in alle Zweige übernommen, die Sicherheitspatches erhalten, derzeit bis hinunter zu 4.7, und nach Bereitschaft veröffentlicht.

#Sicherheitsfixes in WordPress 7.1.1 und 7.1.2

Laut Patchstack erschien zwei Wochen vor 7.1.3 das Release 7.1.2, das eine Schwachstelle behob (CVE-2026-87902). Sie erlaubte einem Besucher ohne Anmeldung, das Einbinden einer lokalen Datei auszulösen, und führte bei passender PHP-Konfiguration zu Remote Code Execution (Patchstack, 6. Oktober 2026).

Zuvor, im September, beschrieb Patchstack außerdem eine Remote-Code-Execution-Lücke, die in 7.1.1 geschlossen wurde. Läuft Ihre Website auf 7.1.0, fehlen ihr die Fixes aus drei aufeinanderfolgenden Releases.

#Was ist die WordPress Core Security Initiative

Am 28. August 2026 kündigte das Sicherheitsteam auf make.wordpress.org die Core Security Initiative an (Make WordPress Security, 28. August 2026). Die Ankündigung verbindet einen “substantial increase” bei den Meldungen mit der schnellen Entwicklung von Frontier-KI-Modellen. Sie beschreibt das als gutes Problem, das aber eine Skalierung von Triage, Verifizierung und Behebung erfordert.

Die Initiative betrifft den WordPress-Core. Plugins und Themes gehören nicht dazu. Meldungen nimmt das Programm auf HackerOne entgegen, Schwachstellen von WordPress.com und den mobilen Apps laufen separat über das Programm von Automattic.

#Wie Patchstack und Wordfence KI-generierte Schwachstellenmeldungen zu Plugins filtern

Die Zahlen von HackerOne betreffen nur den Core. Lücken in Plugins und Themes laufen über andere Programme, und dort zeigt sich dieselbe Kurve. Im März 2026 erhielt das Wordfence Bug Bounty Program 1.718 Schwachstellenmeldungen, 59,4 % mehr als im Februar, von 321 aktiven Forschenden, und zahlte in diesem Monat 62.174 USD an Prämien aus (Wordfence, Bericht März 2026). Wie viele dieser Meldungen mit KI-Hilfe entstanden, sagt der Bericht nicht.

Patchstack benennt die Ursache direkt. Am 29. Mai 2026 schrieb Dave Jong, dort Leiter der Sicherheitsforschung, dass das Programm seit dem Aufschwung KI-gestützter Forschung, besonders im Jahr 2026, mehr Meldungen mit geringer Auswirkung bekommt, die die Kriterien nur knapp erfüllen, mehr Duplikate (eine einzige Schwachstelle zog mehr als 20 doppelte Meldungen verschiedener Forschender nach sich) und Berichte, die auf falschen KI-generierten Annahmen beruhen (Patchstack, 29. Mai 2026). Seit dem 1. Juni 2026 hat Patchstack:

• die Rolle Mitarbeiter (Contributor) aus dem Scope genommen, eine Lücke muss also für Gäste, Abonnenten, Kunden oder eine ähnlich niedrige Rolle erreichbar sein,
• jede Schwachstellenklasse an Bedingungen geknüpft, etwa muss XSS seitenweit wirken oder reflektiert sein,
• den monatlichen Prämienpool auf die besten 5 Forschenden begrenzt,
• eine einwöchige Sperre für alle eingeführt, die falsche KI-generierte Annahmen oder einen nicht am tatsächlichen Plugin oder Theme getesteten Bericht einreichen.

Die Richtlinien in der am 13. Oktober 2026 veröffentlichten Fassung verlangen außerdem einen schrittweisen Proof of Concept in Textform mit rohen HTTP-Requests und exakten Payloads sowie eine Komponente mit mindestens 1.000 aktiven Installationen (Patchstack Bug-Bounty-Richtlinien).

Für Plugin-Autoren zählt dieser Filter mehr als das Core-Budget. Eine Meldung, die die Triage der Plattform besteht, landet trotzdem beim Autor, der sie nachstellen und einen Fix ausliefern muss, meist ohne eigenes Geld aus den Prämien.

#Wer Plugin-Schwachstellen und CVE-Nummern auf WordPress.org bearbeitet

Das Plugin-Verzeichnis hat einen eigenen Weg. Das Plugin Handbook bittet Meldende, zuerst den Entwickler zu kontaktieren und erst wenn das scheitert an [email protected] zu schreiben, ohne das Problem öffentlich zu machen. Das Plugin-Team handelt dann am Eintrag selbst: Die meisten Plugins werden für neue Downloads geschlossen, bis das Problem behoben ist. Dieselbe Seite sagt, dass das Team mangels Ressourcen nicht bei der Beantragung von CVEs hilft (Plugin Handbook, Reporting plugin security issues, zuletzt geändert am 2. Januar 2026).

CVE-Nummern für WordPress-Plugins vergeben deshalb überwiegend Sicherheitsfirmen, die als CVE Numbering Authorities registriert sind. Die Partnerliste des CVE-Programms weist Wordfence Schwachstellen in Plugins, Themes und Core zu, die sein Team entdeckt oder gemeldet bekommt, WPScan den WordPress-Core, Plugins und Themes, und Patchstack Schwachstellen, die sein Team und die Teilnehmenden seines Bug-Bounty-Programms finden (CVE Program, Partnerliste).

Diese Firmen bezahlen die Plugin-Triage aus eigenen Einnahmen und verkaufen darauf Schutz. Wordfence schreibt, dass Premium-, Care- und Response-Nutzer Firewall-Regeln in Echtzeit erhalten, Nutzer der kostenlosen Version nach 30 Tagen. Das ist die zweite Antwort auf die Frage, wer zahlt: Bei Plugins liegen die Triage-Kosten bereits bei Sicherheitsanbietern, und zwei davon, Wordfence und Patchstack, stehen auf Hubbards Liste.

#Was der EU Cyber Resilience Act von Anbietern von WordPress-Plugins verlangt

Seit dem 11. September 2026 ist ein Teil dieser Kosten in der EU auch eine gesetzliche Pflicht. Der Cyber Resilience Act, Verordnung (EU) 2024/2847, gilt vollständig ab dem 11. Dezember 2027, aber Artikel 71 Absatz 2 hat seinen Artikel 14 über Meldepflichten auf den 11. September 2026 vorgezogen (Verordnung (EU) 2024/2847, EUR-Lex). Ein Hersteller, der von einer aktiv ausgenutzten Schwachstelle in seinem Produkt erfährt, muss das als Koordinator benannte CSIRT und die ENISA über eine zentrale Meldeplattform informieren:

Artikel 3 Nummer 13 definiert den Hersteller als jemanden, der ein Produkt entwickelt und unter eigenem Namen oder eigener Marke vermarktet, entgeltlich, zur Monetarisierung oder unentgeltlich. Eine Firma, die ein Premium-Plugin unter ihrer Marke verkauft, fällt direkt unter diesen Wortlaut. Artikel 13 Absatz 6 ergänzt, dass ein Hersteller, der eine Schwachstelle in einer integrierten Komponente findet, auch in einer Open-Source-Komponente, sie demjenigen melden muss, der die Komponente pflegt, und den Fix teilen muss. Verstöße gegen die Artikel 13 und 14 können bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes kosten, je nachdem, welcher Betrag höher ist (Artikel 64 Absatz 2). Kleinst- und Kleinunternehmen sind nur für das Versäumen der 24-Stunden-Frühwarnung von Geldbußen ausgenommen (Artikel 64 Absatz 10).

Verwalter quelloffener Software (open-source software stewards), also juristische Personen, die freie Software für kommerzielle Tätigkeiten systematisch unterstützen, haben ein leichteres Regime: eine dokumentierte Cybersicherheitsstrategie (Artikel 24) und überhaupt keine Geldbußen (Artikel 64 Absatz 10 Buchstabe b). Wer die Triage eines solchen Verwalters bezahlt, regelt die Verordnung nicht, und genau diese Frage stellt Hubbards E-Mail den Firmen auf ihrer Liste.

#Was Betreiber einer WordPress-Website nach 7.1.3 tun sollten

Hubbards Mail ändert an Ihrer Website nichts über Nacht. Die Zahlen von HackerOne und die Liste aus 7.1.3 führen aber zu einigen konkreten Punkten:

1. Installieren Sie 7.1.3, falls noch nicht geschehen. Die Ankündigung empfiehlt die sofortige Aktualisierung. Prüfen Sie unter Dashboard, Aktualisierungen, ob die Website tatsächlich auf 7.1.3 läuft, auch wenn automatische Updates aktiv sind.
2. Ältere Zweige erhalten Patches später. Laut Patchstack kamen die Fixes am Veröffentlichungstag in die Zweige ab 6.6, während die Zweige von 4.7 bis 6.5 noch darauf warteten. Eine Website auf 7.1 war vom ersten Tag an geschützt.
3. Leeren Sie nach dem Update den Cache. Patchstack warnt, dass 7.1.3 in der Datenbank gespeicherte oEmbed-Einbettungen nicht entfernt. Eine früher eingefügte schädliche Imgur-Einbettung wird also weiter ausgeliefert, bis Sie den Cache leeren.
4. Prüfen Sie die Benutzerrollen. Patchstack empfiehlt das ausdrücklich, denn drei der sieben Lücken setzen ein Konto als Mitarbeiter oder Autor voraus. Konten ehemaliger Autoren und Agenturen, die längst nicht mehr für Sie arbeiten, sollten Sie löschen oder herabstufen.
5. Der Core ist nicht alles. Die Core Security Initiative deckt keine Plugins ab. Wenn Sie Ihre Plugins lange nicht geprüft haben, beginnen Sie mit dem Audit veralteter Plugins und bekannter CVEs.
6. Es können weitere Sicherheitsreleases folgen. Hubbard schreibt, das Tempo der Meldungen steige weiter. Wer nur einmal im Quartal aktualisiert, kann mehrere Releases in Folge verpassen. Bei laufender WordPress-Wartung werden Updates auf einer Kopie getestet und innerhalb von Tagen eingespielt, nicht Monaten.

Wenn Sie prüfen möchten, in welchem Zustand Ihre Website gerade ist, beginnen Sie mit einem WordPress-Sicherheitsaudit.

#Bis wann sich Firmen zur Finanzierung verpflichten sollen

Hubbard bot interessierten Firmen detaillierte Programmdaten an und schrieb, sie wolle eine “erste Gruppe von Beitragenden, die in diesem Quartal an unserer Seite stehen” (eigene Übersetzung), also bis Ende Dezember 2026. Bisher hat keine Firma öffentlich einen konkreten Betrag genannt. Ich ergänze ein Update, sobald das eine tut.

#Empfohlene Aktualisierungsfristen nach WordPress 7.1.3 und Patch-Kosten im Wartungsvertrag. Update 10.10.2026

Bis zum 10. Oktober 2026 habe ich keine öffentliche Zusage einer Firma von der Liste gefunden, die Finanzierungslage oben gilt also weiter. Das Risiko lässt sich dagegen genauer fassen. Patchstack bewertet 7.1.3 so:

“Aktualisieren Sie, so bald Sie können, aber das ist kein Notfall, für den man alles stehen und liegen lassen muss.”

Patchstack, WordPress 7.1.3 security release, 6. Oktober 2026, eigene Übersetzung

Eine der sieben Korrekturen greift ohne Konto und ohne Zutun des Opfers, drei meldete Anthropic. Für Betreiber heißt das: Core-Patch innerhalb weniger Tage, nach einem Test auf einer Kopie, nicht im nächsten Quartal.

Das Geld, um das Hubbard bittet, deckt Prämien und Triage im Core. Die Arbeit an Ihrer eigenen Seite (Test, Einspielen, Plugin-Prüfung) ist ein eigener Posten, den der Vertrag benennen muss. Fragen Sie Ihren Dienstleister für die WordPress-Wartung drei Dinge: wie viele Tage nach einem Sicherheitsrelease das Core-Update live geht, ob es vorher auf Staging getestet wird und ob ein Release außerhalb des Zyklus im Paket enthalten ist.

Letzte Aktualisierung: 13. Oktober 2026.