Seit dem Frühjahr 2026 erscheinen WordPress-Sicherheitsreleases nicht mehr im Quartalsrhythmus, sondern gelegentlich zweimal in einer Woche. Der Grund ist nicht schlechterer Code, sondern eine KI-gestützte Schwachstellensuche, die schneller findet als früher jedes Forscherteam. Für Betreiber wackelt damit eine stille Annahme, auf der viele Wartungsabsprachen beruhen: dass ein Update auch nächste Woche noch reicht. Dieser Beitrag zeigt, was sich 2026 messbar geändert hat, welcher Update-Zyklus daraus folgt und wo Automatik hilft und wo nicht.
1. Was sich 2026 geändert hat: Lücken werden maschinell gefunden
Kurze WordPress Update-Zyklen sind 2026 keine Vorsichtsmaßnahme mehr, sondern eine direkte Reaktion auf eine veränderte Bedrohungslage. Ende August 2026 veröffentlichte das WordPress-Sicherheitsteam die Core Security Initiative und begründete sie mit einem starken Anstieg eingehender Sicherheitsmeldungen, der großteils auf die wachsende Fähigkeit aktueller KI-Systeme zurückgehe, Code auf Schwachstellen zu analysieren.
Die Zahlen sind öffentlich. Nach Angaben von Sicherheitsteam-Vertreter John Blackbourn, zitiert von The Repository, lagen die monatlichen Meldungen im HackerOne-Programm ein Jahrzehnt lang bei 20 bis 30. Im August 2026 waren es 773, woraufhin das Team den Geltungsbereich einschränkte. Auch Patchstack hat sein Bug-Bounty-Programm umgebaut und nennt als Anlass die gestiegene Zahl von Meldungen durch KI-gestützte Sicherheitsforschung. Der Fahrplan zu WordPress 7.2 sieht für Dezember 2026 unter anderem einen Sudo-Modus und eine Secrets-API vor.
2. Die Belege stehen im Changelog
WordPress 7.0 erschien laut offizieller Versionsübersicht am 20. Mai 2026. Was danach kam:
- 7.0.3, 6. August 2026: zwölf Korrekturen. Die schwerste war laut Release-Ankündigung ein Cross-Site-Scripting auf der Login-Seite ohne vorherige Anmeldung, gemeldet von pwn.ai. Patchstack listet die Bandbreite auf: XSS, Rechteausweitung, Informationsabfluss, SSRF und mehr.
- 7.0.4, 12. August 2026: sechs Tage später eine einzige Korrektur, Codeausführung aus der Ferne durch Datei-Upload bei Websites mit Imagick und Ghostscript, erneut von pwn.ai, nach Analyse von Nebula Design eine autonome Pentesting-Plattform, CVE-2026-65640 mit CVSS 8.8.
- 7.1.1 und 7.0.5, 17. September 2026: elf Schwachstellen. In den Danksagungen stehen laut The Repository zwei Meldungen von Anthropic und eine von pwn.ai.
- 7.1.2 und 7.0.6, 22. September 2026: eine kritische Korrektur. Ein nicht angemeldeter Angreifer konnte beliebige PHP-Dateien außerhalb der Theme-Verzeichnisse einbinden, gemeldet von Robert Ressl. Patchstack ordnet das als schwerwiegendsten Core-Fund seit längerem ein, geführt als CVE-2026-87902.
Vier Sicherheitsreleases in sieben Wochen, zwei davon kritisch oder hoch bewertet, mehrfach gefunden mit KI-Unterstützung.
3. Fünf Stunden: das Zeitfenster zwischen Patch und Angriff
Eine veröffentlichte Lücke ist eine Bauanleitung. Patchstack hat für seinen Bericht State of WordPress Security in 2026 gemessen: Der gewichtete Median von öffentlicher Bekanntgabe bis zur massenhaften Ausnutzung liegt bei fünf Stunden. Im selben Bericht: 46 Prozent der Schwachstellen waren zum Zeitpunkt der Veröffentlichung noch nicht behoben.
Die Veröffentlichung eines Patches ist kein Abschluss, sondern ein Startschuss. Wer nach dem Release eine Woche bis zum Einspielen braucht, verbringt diese Woche auf einer Website, deren Lücke öffentlich dokumentiert ist.
4. Das größere Risiko liegt in Plugins und Themes
Patchstacks Jahresbericht zählte für 2025 insgesamt 11.334 neue Schwachstellen im WordPress-Umfeld, ein Plus von 42 Prozent, und 91 Prozent steckten in Plugins, so The Repository. Die Datenbank von Wordfence listet aktuell über 10.400 Plugins mit bekannten Schwachstellen.
Für Ihre Website heißt das: Die Rechnung lautet nicht „WordPress plus Updates“, sondern „WordPress plus 25 Plugins plus Theme plus deren Update-Disziplin“. Warum sich das auch ohne akuten Vorfall lohnt, haben wir im Beitrag Warum Sie Ihre Plug-ins regelmäßig updaten sollten beschrieben.
5. Warum automatische Updates die Frage nicht erledigen
Kleine Core-Releases werden seit Version 3.7 standardmäßig im Hintergrund installiert. Bei Plugins und Themes endet die Automatik: Laut offizieller Dokumentation müssen Administratoren die automatische Aktualisierung seit WordPress 5.5 einzeln pro Plugin und Theme einschalten. Ohne diese Freigabe greift die Automatik laut Entwicklerdokumentation nur in Sonderfällen als Notbremse des Sicherheitsteams.
Zwei weitere Grenzen: WordPress 6.6 kann ein fehlgeschlagenes Plugin-Update zurückrollen, aber nur bei einem PHP-Fatal-Error; für Themes gibt es das nicht. Und Erweiterungen, die nicht aus dem offiziellen Verzeichnis stammen, melden Aktualisierungen nicht zwangsläufig im Backend.
6. WordPress Update-Zyklen absichern: auch Updates fallen aus
Am 10. März 2026 erschien WordPress 6.9.2 mit zehn Sicherheitskorrekturen und legte Websites mit einer weißen Seite still. Fünf Stunden später kam 6.9.3, einen Tag darauf 6.9.4, so das Search Engine Journal. Ein Dienstleister, der 336 Websites sofort aktualisiert hatte, meldete rund 10 Prozent Ausfälle.
Die Lehre ist nicht „langsamer aktualisieren“, sondern: aktualisieren mit Netz. Ein Backup vor dem Update, eine Testumgebung für alles jenseits einfacher Patches, und ein Mensch, der nach dem Einspielen die wichtigsten Seiten aufruft. Dafür gibt es in unseren Hosting-Paketen eine Testumgebung.
7. Was ein kurzer Zyklus praktisch bedeutet
Der reguläre Durchgang: Ein fester Termin pro Woche, in dem Core, Plugins und Theme in der Testumgebung aktualisiert, geprüft und live übernommen werden. Davor ein Backup, danach eine kurze Prüfliste.
Der Ausnahmefall: Für kritische Lücken ohne Anmeldung brauchen Sie einen Weg, der in Stunden funktioniert. Klären Sie schriftlich: Wer darf ohne Rückfrage einspielen, und wer ist am Wochenende erreichbar?
Drei Vorarbeiten machen den Zyklus tragfähig:
- Inventur. Alle Plugins und Themes mit Herkunft, Lizenzstatus und Zuständigkeit erfassen. Nicht benötigte Erweiterungen löschen, nicht nur deaktivieren.
- Benachrichtigung. Schwachstellenmeldungen von Wordfence oder Patchstack abonnieren.
- Rückweg testen. Die Wiederherstellung aus dem Backup einmal in der Testumgebung ausprobieren.
8. Auf der alten Version bleiben ist keine Lösung
Der Überblick von endoflife.date hält fest: Offiziell unterstützt ist nur die jeweils neueste WordPress-Version. Sicherheitskorrekturen werden auf ältere Zweige zurückportiert, wenn möglich, ohne Garantie.
Und die technische Schutzschicht darunter trägt weniger als erwartet: Laut Patchstacks Bericht blockierten übliche Hosting-Verteidigungen nur 12 Prozent der Angriffe bei bekannten, aktiv ausgenutzten Schwachstellen. Eine Firewall verschafft Zeit. Das Update beseitigt die Ursache.
9. Ab wann sich ein Wartungsvertrag lohnt
Der Agenturvergleich 2026 von Dr. Web gibt den Markt für laufende WordPress-Wartung mit 30 bis 300 Euro monatlich an.
Die Entscheidung lässt sich an drei Prüffragen festmachen: Können Sie innerhalb von 24 Stunden nach einem kritischen Release ein Backup anlegen, das Update testen und live schalten? Haben Sie eine benannte Person, die auch am Wochenende erreichbar ist? Bewerten Sie wöchentlich die Schwachstellenmeldungen Ihrer installierten Plugins? Sobald Sie eine dieser Fragen mit Nein beantworten, ist ein Wartungsvertrag mit festgelegter Reaktionszeit günstiger als das Risiko einer offenen Lücke. Wie wir das konkret organisieren, steht auf unserer Seite zur WordPress-Pflege.
10. Fazit
Entscheiden Sie als Erstes nicht über ein Wartungspaket, sondern über eine Zahl: Wie viele Stunden darf zwischen einem kritischen Sicherheitsrelease und dem Einspielen auf Ihrer Website liegen? Alles Weitere folgt daraus. Wer bei 24 Stunden landet, braucht eine Testumgebung, eine Bereitschaft und eine Person mit Entscheidungsbefugnis. Wer bei zwei Wochen landet, sollte wissen, dass die Angriffe nach Patchstacks Messung längst laufen.
Dass WordPress derzeit häufiger Sicherheitsupdates ausliefert, ist kein Argument gegen das System. Es ist das sichtbare Ergebnis davon, dass mehr und schnellere Werkzeuge den Code prüfen. Den Vorteil daraus hat nur, wer die Ergebnisse auch einspielt.