Einleitung
WordPress.org hält heute jedes neue Plugin-Release bis zu sechs Stunden zurück, bevor es die Auto-Updates erreicht. Patchstack misst die mediane Zeit von der Veröffentlichung einer Schwachstelle bis zur Masseausnutzung mit fünf Stunden. Beide Zahlen stehen seit Juli nebeneinander im öffentlichen Raum, und niemand hat sie nebeneinandergelegt.
Kurz gefasst
- Sechs Stunden beträgt heute die Wartezeit für ein Plugin- oder Theme-Release im Rahmen der Initiative Protect the Shire. Start am 5. Juni 2026 mit bis zu 24 Stunden, Verkürzung auf sechs vor dem 18. Juli 2026.
- Fünf Stunden ist die mediane Zeit bis zur Masseausnutzung einer folgenreichen Schwachstelle, laut Patchstack, State of WordPress Security in 2026 vom 25. Februar 2026.
- 46 Prozent der Schwachstellen haben zum Zeitpunkt der Veröffentlichung keinen Patch. Diese Zahl stammt aus demselben Bericht und verändert die Bedeutung der beiden ersten.
- Ob ein Sicherheitspatch von der Wartezeit ausgenommen ist, steht nirgends. Die Ankündigung spricht von jedem neuen Release und trifft keine Unterscheidung.
- Die Verkürzung auf sechs Stunden wurde ausschließlich im Slack angekündigt. Plugin-Autoren erfuhren davon beim eigenen Release.
- 11.334 neue Schwachstellen im Ökosystem im Jahr 2025, 42 Prozent mehr als im Vorjahr, leicht ausnutzbare stiegen um 113 Prozent.
- 12 Prozent der bekannten WordPress-Angriffe halten übliche Hosting- und WAF-Konfigurationen auf. Diese Zahl beschneidet den Rat, den ich weiter unten selbst gebe.
Woher die Wartezeit kommt
Im April 2026 flogen einunddreißig Plugins einer einzigen Marke auf einmal aus dem Verzeichnis. Jedes trug eine Hintertür. Eingebrochen wurde nirgends: Jemand kaufte die Plugins auf Flippa, erbte damit den SVN-Zugang und schob ein einziges bösartiges Update nach, getarnt als Kompatibilitätspatch für WordPress 6.8.2.
Es lohnt sich, diesen Angriff in seine Schritte zu zerlegen, denn jeder einzelne ist für sich legal und erst zusammen ergeben sie eine Kompromittierung. Ein Plugin auf einem Marktplatz zu kaufen ist legal. Den Repository-Zugang mitzuerben entspricht den Regeln, denn so sieht ein Eigentümerwechsel aus. Ein Update zu veröffentlichen ist die normale Tätigkeit eines Autors. Es als Kompatibilitätspatch für ein bestimmtes WordPress-Release zu kennzeichnen ist plausibel, weil solche Patches damals tatsächlich erschienen. Die Reichweite wurde mit bis zu 400.000 Websites angegeben.
Kein Glied dieser Kette wirkt für sich verdächtig, und genau darum geht es. Eine Kontrolle, die darauf beruht, wer den Code veröffentlicht, hatte nichts zu erkennen, denn veröffentlicht hat ihn der rechtmäßige Eigentümer. Erkennbar war ausschließlich, was darin steckte.
Das ist ein Lieferkettenangriff in Reinform, und das Verzeichnis hatte darauf keine Antwort, weil das gesamte Vertrauensmodell auf der Annahme beruhte, wer Commit-Rechte hat, sei auch der, für den er sich ausgibt. Protect the Shire beantwortet genau dieses Szenario. Zwischen Commit und Verteilung wird ein Fenster eingezogen, in dem ein automatischer Prüfer und ein Mensch ansehen können, was gleich an Millionen Installationen geht.
Als Antwort auf jenen Angriff ergibt die Wartezeit Sinn, und das will ich klar sagen, bevor ich zum Einwand komme. Sechs Stunden zwischen einem bösartigen Commit und dem Auto-Update sind sechs Stunden, die es vorher nicht gab.
Wo die sechs Stunden aufhören zu helfen
Die Wartezeit ist neutral gegenüber dem Inhalt eines Releases. Sie weiß nicht, ob darin eine neue Funktion, eine Tippfehlerkorrektur oder ein Patch für eine aktiv ausgenutzte Schwachstelle steckt. Die Ankündigung vom 5. Juni spricht von jedem neuen Release und trifft keine Unterscheidung. Ich habe auch keine Quelle gefunden, die einen beschleunigten Weg für Sicherheitsreleases beschreibt.
Ich will hier genau sein, denn an dieser Stelle schreibt man leicht etwas Unwahres. Ich behaupte nicht, dass es keinen beschleunigten Weg gibt. Ich behaupte etwas Schwächeres und Überprüfbares: Er ist dort nicht dokumentiert, wo ein Plugin-Autor ihn suchen würde, nämlich in der Ankündigung und den nachfolgenden öffentlichen Beiträgen. Für einen Autor, der gerade eine Schwachstellenmeldung erhalten hat und ein Notfallrelease vorbereitet, ist ein undokumentierter Weg praktisch dasselbe wie kein Weg.
Und hier landet die zweite Zahl. Patchstack beziffert die mediane Zeit bis zur Masseausnutzung einer folgenreichen Schwachstelle auf fünf Stunden nach der Veröffentlichung. Median, nicht Mittelwert, die Hälfte der Fälle läuft also schneller.
Die beiden Zahlen nebeneinanderzustellen verlangt Sorgfalt, denn sie messen Verschiedenes. Sechs Stunden sind eine Verzögerung bei der Verteilung eines Updates. Fünf Stunden sind die Zeit von der Veröffentlichung bis zum Angriff im großen Stil. Sie decken sich nicht sauber, und ich behaupte nicht, dass jeder Patch eine Stunde zu spät kommt. Ich behaupte, dass das Schutzfenster des Verzeichnisses in derselben Größenordnung liegt wie das Angriffsfenster, und bei diesem Verhältnis ist das Puffern eines Releases nicht mehr kostenlos.
Die Zahl, die die beiden anderen verändert
Derselbe Patchstack-Bericht nennt 46 Prozent der Schwachstellen ohne Patch zum Zeitpunkt der Veröffentlichung.
Diese Zahl verschiebt die ganze Diskussion. In fast der Hälfte der Fälle gibt es nichts zurückzuhalten, weil es noch kein Release gibt. Die Wartezeit kostet dort nichts, bringt aber auch nichts, und das Einzige, was eine Website schützt, ist eine Schicht, die nicht auf das Verzeichnis wartet: eine WAF-Regel, eine abgeschaltete Funktion, ein deaktiviertes Plugin.
Praktisch heißt das, die Debatte über sechs Stunden betrifft etwas mehr als die Hälfte der Fälle. Für den Rest lautet die Frage völlig anders, und das Verzeichnis ist darin keine Partei.
Der Maßstab, der sechs Stunden überhaupt bedeutsam macht
Sechs Stunden klingen harmlos, bis man sie der Zahl der Ereignisse gegenüberstellt, die durch dieses Fenster laufen.
Patchstack zählte 11.334 neue Schwachstellen im WordPress-Ökosystem im Jahr 2025, 42 Prozent mehr als im Vorjahr. Das sind im Schnitt mehr als dreißig pro Tag. Ein steigendes Volumen allein wäre erträglich, wenn es gleichmäßig stiege, tut es aber nicht: Als leicht ausnutzbar eingestufte Schwachstellen stiegen um 113 Prozent im Jahresvergleich, haben sich also mehr als verdoppelt.
Zusammen verändern diese beiden Zahlen den Charakter des Problems. Es sind nicht einfach mehr Lücken. Am schnellsten wächst der Anteil, der sich ohne Aufwand ausnutzen lässt, also in großem Maßstab und maschinell. Bei diesem Profil ist ein Median von fünf Stunden bis zur Masseausnutzung keine statistische Kuriosität mehr, sondern die Beschreibung eines normalen Tages.
In diesem Licht ist eine Wartezeit im Verzeichnis einer der wenigen Hebel, die überhaupt im Maßstab wirken. Ein automatischer Prüfer, der jedes Release ansieht, skaliert besser als jeder Prozess, der davon abhängt, dass ein Plugin-Autor oder ein Administrator rechtzeitig reagiert. Deshalb halte ich die Richtung für richtig, und der Streit dreht sich allein darum, ob das Fenster blind für den Inhalt eines Releases bleiben soll.
Eine Korrektur an meinem eigenen Rat
Ich habe oben geschrieben, man solle eine Schicht bauen, die nicht auf das Verzeichnis wartet, und auf eine WAF-Regel gezeigt. Derselbe Patchstack-Bericht enthält eine Zahl, die diesen Rat deutlich beschneidet, und ich werde sie nicht unterschlagen.
In Penetrationstests blockierten übliche Hosting- und WAF-Konfigurationen 12 Prozent der bekannten, aktiv ausgenutzten WordPress-spezifischen Angriffe und 26 Prozent eines breiteren Testsatzes. Acht von zehn realen Angriffen gehen glatt durch das hindurch, was die meisten Agenturen für ihre Schutzschicht halten.
Die Unterscheidung, die den Rat rettet, ist konkret und gehört benannt. Eine generische Hosting-WAF filtert generische Muster, plumpe SQL-Injection-Versuche und Pfad-Scans. Eine Schwachstelle in einem konkreten Plugin sieht meist nicht wie ein generischer Angriff aus. Sie sieht aus wie eine gültige Anfrage an einen gültigen Endpunkt mit einem Parameter, den der Autor so nicht vorgesehen hat. Eine generische Regel sieht das nicht.
Eine Regel, die gegen ein konkretes, veröffentlichtes CVE geschrieben ist, ist etwas anderes, in der Branche Virtual Patching genannt. Sie muss keine Angriffsklasse verstehen, sie braucht nur die Signatur dieses einen Falls. Das ist die Schicht, die ich meinte, und ich will genau sein: Es geht nicht darum, eine WAF zu besitzen, sondern darum, einen Prozess zu haben, der binnen Stunden nach Veröffentlichung eine Regel nachlegt. Eine WAF bloß zu haben ist weniger wert, als allgemein angenommen wird.
Dazu gehört ein ehrlicher Vorbehalt zur Quelle. Patchstack verkauft Virtual Patching, eine Zahl, die generische WAFs schwach aussehen lässt, kommt dem Unternehmen also gelegen. Das macht sie nicht falsch, und die Methodik ist im Bericht als Penetrationstest gegen einen bekannten Exploit-Satz beschrieben. Es heißt nur, dass man die Zahl mit dem Wissen lesen sollte, wer sie veröffentlicht. Ich erwähne es, damit es niemand selbst herausfinden muss.
Die Seite des Plugin-Autors, die halbe Miete
Bis hierher habe ich aus der Position dessen geschrieben, der fremde Websites betreut. Ein Plugin-Autor hat dasselbe Problem umgekehrt, und seine Fassung ist härter, denn er sitzt an der Uhr.
Das Szenario läuft so. Sie erhalten eine Schwachstellenmeldung, meist über ein Bug-Bounty-Programm oder direkt von einem Forscher. Sie vereinbaren ein Veröffentlichungsdatum, bereiten den Patch vor, testen, veröffentlichen das Release. Bis Juni 2026 lagen zwischen Commit und Verteilung Minuten. Jetzt sind es bis zu sechs Stunden, und es gibt keinen öffentlich dokumentierten Weg, das abzukürzen.
Praktisch folgt daraus, dass das mit dem Forscher vereinbarte Datum Puffer braucht. Wenn Sie die Veröffentlichung auf Montag neun Uhr legen, muss das Release Sonntagabend raus, nicht Montag um acht. Gegen einen Median von fünf Stunden bis zur Masseausnutzung ist diese eine Stunde real.
Die zweite Folge betrifft die Rufbereitschaft. Der Entwickler Lopo hat es am kürzesten gesagt: erst nach dem Release zu erfahren, dass Schichten umgestellt werden müssen, um den Rollout zu begleiten. Wer ein Plugin mit einer halben Million Installationen veröffentlicht, braucht jemanden, der in den Stunden auf Meldungen schaut, in denen das Update tatsächlich ausrollt. Bei einem beweglichen und nicht öffentlich angekündigten Fenster lässt sich das nicht planen.
Die dritte ist subtiler. Die Wartezeit verändert, was eine Versionsnummer bedeutet. Bisher hieß das Veröffentlichen von 2.4.1, dass 2.4.1 im Umlauf ist. Jetzt heißt es, dass sie es sein wird, und in der Zwischenzeit ist 2.4.0 im Umlauf, also die verwundbare Version, von der bereits öffentlich bekannt ist, dass sie verwundbar ist. Die Release-Notes müssen das berücksichtigen, sonst ist “behoben in 2.4.1” zugleich wahr und irreführend.
Gandalf, oder Vertrauen verschoben statt abgeschafft
Die Wartezeit prüft für sich genommen nichts. Es zählt, was während ihr geschieht, und diese Rolle fällt in der Ankündigung einem automatischen Prüfer namens Gandalf zu.
Es lohnt sich zu bemerken, was sich im Vertrauensmodell tatsächlich geändert hat. Bis April vertraute das Verzeichnis demjenigen, der den SVN-Zugang hielt. Nach April ist bekannt, dass dieser Zugang mitunter zusammen mit dem Plugin gekauft wird, das Vertrauen wurde also von dieser Stelle abgezogen. Abgeschafft wurde es nicht, es wurde auf einen automatischen Prüfer verschoben, der den Inhalt eines Releases bewertet.
Das ist die bessere Lösung, und ich sage das klar, denn ein automatischer Prüfer lässt sich nicht auf Flippa kaufen. Sie wirft allerdings zwei neue Fragen auf, die der öffentliche Stand nicht beantwortet.
Die erste betrifft Fehler in der Gegenrichtung. Ein Scanner, der ein bösartiges Release durchlässt, ist das offensichtliche Problem. Ein Scanner, der ein legitimes Release blockiert, ist das leisere und für den Autor schmerzhaftere, denn es ist unklar, an wen man sich wendet und wie lange es dauert. Eine Beschreibung eines Einspruchsverfahrens habe ich nicht gefunden.
Die zweite betrifft die Dauer des Scans selbst. Dauert er zwanzig Minuten, ist das Sechs-Stunden-Fenster zu fünfundneunzig Prozent Puffer statt Arbeit, und der Vorschlag, die Wartezeit bei sauberem Ergebnis zu überspringen, löst praktisch das ganze Problem. Dauert er fünf Stunden, gilt das Gegenteil. Diese eine Zahl verändert die Schlussfolgerung und ist nicht veröffentlicht.
Slack ist kein Ankündigungskanal
Die Verkürzung von 24 auf sechs Stunden kam ohne öffentlichen Beitrag. Ajay D’Souza fand sie beim Veröffentlichen eines Plugins vor dem 18. Juli 2026. Enrico Battocchi fragte direkt, wie man von solchen Änderungen erfahren solle und ob es einen Beitrag geben werde. Ein Entwickler namens Lopo beschrieb die betrieblichen Kosten.
Das ist ein vom eigentlichen Fenster getrenntes Problem und aus meiner Sicht das schwerwiegendere. Ein Plugin-Autor plant ein Notfallrelease um eine bekannte Verzögerung herum. Ändert sich die Verzögerung ohne Ankündigung, bricht die Planung in beide Richtungen. Mal wartet man länger als kalkuliert, mal geht es früher raus und niemand beobachtet den Rollout.
Es existiert ein Entwurf, die Wartezeit zu überspringen, wenn der Gandalf-Scan nichts findet. Die geprüfte Version wartet dann nicht länger, sondern wird ausgeliefert. Das würde den größten Teil des Problems lösen, denn ein sauberer Scan ist die überwältigende Mehrheit der Releases. Der Vorschlag ist in Prüfung und nicht umgesetzt.
Was auf der Website-Seite zu tun ist
Wer Kundenwebsites betreut, hat auf die Wartezeit im Verzeichnis keinen Einfluss. Auf vier andere Dinge schon.
Schalten Sie Auto-Updates nicht als Reaktion auf diese Änderung ab. Das ist der häufige Reflex und das Gegenteil dessen, was die Zahlen tragen. Die Wartezeit kostet Stunden. Manuelles Klicken kostet Tage, und über sechs Sprachen und Dutzende Websites kostet es Wochen. Da die Hälfte der kritischen Fehler in den ersten 24 Stunden ausgenutzt wird, ist Ihre eigene Reaktionszeit das größere Risiko.
Es hilft, die Rechnung anzusehen. Die Wartezeit fügt höchstens sechs Stunden hinzu. Wöchentliches manuelles Aktualisieren ergibt im Mittel rund vierundachtzig Stunden Verzug, das Vierzehnfache. Selbst tägliches manuelles Aktualisieren ergibt im Mittel zwölf Stunden, immer noch das Doppelte des Verzeichnisfensters. Wer also argumentiert, die Wartezeit sei zu riskant, und deshalb auf manuell umstellt, tauscht sechs Stunden gegen mehrere Dutzend.
Bauen Sie den Prozess für das Nachlegen einer Regel, nicht bloß die WAF. Nach der Korrektur oben liest sich dieser Rat anders als üblich. Eine Hosting-WAF zu besitzen hält laut Patchstack zwölf Prozent der bekannten WordPress-Angriffe auf. Der Wert liegt darin, binnen Stunden eine Regel für ein konkretes, frisch veröffentlichtes CVE nachlegen zu können. Das ist der Unterschied zwischen einem Produkt und einem Verfahren, und hier entscheidet das Verfahren.
Führen Sie je Kunde eine Liste der geschäftskritischen Plugins und wissen Sie, welches sich eine Stunde abschalten lässt. Ein Formular-Plugin zu deaktivieren, bis der Patch da ist, ist billig. Ein Zahlungs-Gateway zu deaktivieren nicht. Diese Unterscheidung gehört in ein Dokument, das vor dem Vorfall geschrieben wird, nicht während. Praktisch ist es eine Spalte in einer Tabelle, einmal beim Onboarding ausgefüllt.
Wissen Sie, woher Sie von einer Schwachstelle erfahren, bevor Sie es vom Monitoring erfahren. Der Informationskanal zählt hier so viel wie die technische Schicht, denn gegen einen Median von fünf Stunden ist der Unterschied zwischen morgens und abends der Unterschied zwischen Patch und Vorfall. Ein täglich gelesener Schwachstellen-Feed ist billiger als jedes Werkzeug und setzt die Obergrenze dafür, wie schnell Sie überhaupt reagieren können.
Was diese Änderung nicht behebt
Es lohnt sich klar zu sagen, was die Wartezeit nicht berührt, denn man überschätzt sie leicht.
Sie berührt keine Plugins außerhalb des Verzeichnisses. Ein Premium-Plugin, direkt beim Autor oder auf einem Marktplatz gekauft, aktualisiert über seinen eigenen Kanal, und keine Wartezeit erfasst es. In einem typischen WooCommerce-Shop laufen davon mehrere, oft die heikelsten, denn sie berühren Zahlungen, Versand und Kundendaten.
Sie berührt auch keine Themes und Plugins, die von Hand aus einer ZIP-Datei installiert wurden, und keinen Code im eigenen Funktions-Plugin eines Kunden. Und genau dort sitzt üblicherweise die meiste Schuld, in Code, der nebenbei geschrieben und jahrelang nicht angefasst wurde.
Schließlich berührt sie nicht den Fall, in dem gar nicht der Code das Problem ist, sondern die Konfiguration: zu weite Rechte, ein Administratorkonto ohne zweiten Faktor, ein API-Schlüssel im Repository. Das Verzeichnis spielt dort keine Rolle, und der Anteil solcher Fälle an realen Vorfällen ist hoch.
Was ich nicht weiß
Drei Dinge bleiben offen, weil ich keine Quelle dafür habe und nicht raten werde.
Ich weiß nicht, ob Sicherheitsreleases einen beschleunigten Weg haben, der nicht öffentlich dokumentiert ist. Ich weiß nicht, wie lange ein vollständiger Gandalf-Scan tatsächlich dauert, also weiß ich nicht, wie viel der sechs Stunden Arbeit und wie viel Puffer ist. Ich weiß nicht, wann und ob der Vorschlag umgesetzt wird, die Wartezeit bei sauberem Scan zu überspringen.
Sobald eines davon öffentlich dokumentiert ist, aktualisiere ich diesen Beitrag und datiere die Änderung.
Quellen
- Protect The Shire, WordPress News, 5. Juni 2026
- Patchstack, State of WordPress Security in 2026, 25. Februar 2026
- Die Verkürzung auf sechs Stunden und die Reaktion der Entwickler
Zuletzt geprüft: 10. August 2026.
