Das WordPress-Team hat bekanntgegeben, dass für jedes Plugin-Update vor dessen Auslieferung über die WordPress.org-API ein automatisierter Sicherheitsaudit eingeführt wird. Das System nutzt KI-Modelle und Jetpack Scan, um die Codeänderungen zu analysieren, dem Release einen Risikowert zuzuweisen und die Verbreitung von Updates mit hohem Score automatisch zu blockieren – ohne Eingreifen des Moderatorenteams. Die Neuerung betrifft alle Entwickler von WordPress-Plugins und -Themes sowie Administratoren von Websites, die automatische Updates über das WordPress-Dashboard nutzen.
Das Problem: Updates ohne Kontrolle
Bisher wurden neue Plugins vor der Aufnahme in das Verzeichnis WordPress.org manuell geprüft, spätere Updates jedoch ohne jeglichen systematischen Audit veröffentlicht. Wie David Perez, einer der Leiter des Teams des offiziellen Plugin-Repositorys, erläuterte: „Ein Plugin kann heute sicher sein, aber in der nächsten Version taucht eine Schwachstelle oder Schadcode auf“. Dass es zwischen dem Commit eines Updates und seiner Auslieferung an Millionen von Websites keine Zwischenschicht der Prüfung gab, eröffnete ein Fenster für Angriffe auf die Lieferkette.
Das Problem ist nicht nur theoretischer Natur. Nach Angaben von WordPress hat das automatische System am 28. Juli 2026 eine Backdoor in einem Update eines nicht näher benannten Plugins mit rund 20 000 aktiven Installationen entdeckt. Die kompromittierte Version wurde nicht über die WordPress.org-API verteilt, da sie sich noch im Zeitraum der Wartezeit (cooldown) befand. Das Plugin wurde 26 Minuten, nachdem das WordPress-Team von Wordfence benachrichtigt worden war, für Downloads gesperrt. Dabei ist zu beachten, dass WordPress den Namen des Plugins nicht offengelegt hat und es in offenen Quellen keine unabhängige Bestätigung dieses Vorfalls gibt.
So funktioniert das neue System
Seit dem 5. Juni 2026 müssen alle WordPress-Plugins und -Themes vor der Verteilung über die Update-API eine verpflichtende Wartezeit durchlaufen – das ist Teil der Initiative Protect The Shire. Anfangs betrug diese Verzögerung bis zu 24 Stunden, später wurde sie jedoch auf aktuell sechs Stunden reduziert. Die neue automatische Prüfung ist genau in dieses Zeitfenster eingebettet und funktioniert wie folgt:
- Während der Wartezeit werden die Änderungen jedes Releases von mehreren KI-Modellen gemeinsam mit Jetpack Scan analysiert.
- Die Ergebnisse werden gegenseitig abgeglichen und zu einer abschließenden Sicherheitsbewertung zusammengeführt: Je höher der Score, desto höher das potenzielle Risiko.
- Releases mit hoher Risikobewertung werden nach Abschluss der Prüfung automatisch blockiert. Updates unterhalb des Schwellwerts durchlaufen den normalen Veröffentlichungsprozess.
- Entwickler erhalten nur dann eine E-Mail mit den Prüfergebnissen, wenn ein Release blockiert wurde.
Wichtiger Hinweis: Eine hohe Risikobewertung bedeutet nicht zwingend, dass Schadcode vorhanden ist. WordPress weist ausdrücklich darauf hin, dass eine versehentlich eingeführte Schwachstelle denselben hohen Score erhalten kann wie eine absichtlich platzierte Backdoor. Das System misst Risiko, nicht Absicht.
Code-Muster, die die Risikobewertung erhöhen
WordPress hat eine konkrete Liste von Mustern veröffentlicht, auf die das System reagiert:
- REST-, AJAX- und admin-post-Endpunkte ohne Berechtigungsprüfung (ein Nonce ist für sich genommen keine Autorisierung);
- SQL-Abfragen, die ohne
$wpdb->prepare()aufgebaut werden; - Dateioperationen (Pfade, Uploads, Löschungen, Includes), die auf Daten aus einer Anfrage basieren;
- Aufrufe von
unserialize()für Daten aus Anfragen oder entfernten Antworten; - Schreiben in Optionen, Benutzermetadaten oder Einstellungen aus Endpunkten, die für Abonnenten oder nicht authentifizierte Benutzer zugänglich sind;
- Nachladen und Ausführen von Code zur Laufzeit, verschleierter oder gepackter Code.
Entwicklern wird empfohlen, ihren Code mit den WordPress Coding Standards und PHP_CodeSniffer zu prüfen. Autoren von Erweiterungen für WooCommerce wird nahegelegt, die Plattform Quality Insights Toolkit zu verwenden.
Was tun, wenn ein Release blockiert wird
Die einzige Möglichkeit, eine Blockierung aufzuheben, besteht darin, die identifizierten Probleme zu beheben und eine neue Version zu veröffentlichen. Erhält das aktualisierte Release einen Score unterhalb des Blockierungsschwellwerts, durchläuft es den regulären Prozess mit einer sechsstündigen Wartezeit. Entwickler können das Ergebnis beim Plugins Team anfechten, doch wie Perez anmerkt, ist das Veröffentlichen einer korrigierten Version fast immer schneller, als auf eine manuelle Prüfung der Beschwerde zu warten.
Bewertung der Auswirkungen
Die Neuerung betrifft das gesamte WordPress.org-Ökosystem – jedes Plugin und jedes Theme, das über die offizielle Update-API verteilt wird, einschließlich der One-Click-Updates aus dem Dashboard. Für Entwickler bedeutet das, dass sie die Coding-Standards noch genauer einhalten müssen: Selbst unbeabsichtigte Sicherheitsfehler können zu einer Blockierung des Releases und einer Verzögerung bei der Auslieferung von Updates an die Nutzer führen.
Gleichzeitig erfasst das System ausschließlich den Verteilungskanal WordPress.org. Plugins, die aus Drittquellen installiert oder über eigene Mechanismen der Entwickler aktualisiert werden, fallen nicht unter diese Prüfung. Früher haben wir bereits über Schwachstellen in WordPress-Plugins berichtet, und genau darauf zielt das neue System ab: solche Situationen bereits auf der Ebene der Verteilung zu verhindern.
Die automatische Sicherheitsprüfung ist eine logische Weiterentwicklung der Initiative Protect The Shire, die Schritt für Schritt einen mehrstufigen Schutz der WordPress-Lieferkette aufbaut. Administratoren von WordPress-Websites müssen keine zusätzlichen Maßnahmen ergreifen: Das System läuft auf Seiten von WordPress.org. Plugin-Entwickler sollten ihren Code jedoch schon jetzt durch die WordPress Coding Standards und PHP_CodeSniffer laufen lassen, damit der nächste Release nicht aufgrund von Mustern blockiert wird, die das System als riskant einstuft.
