WordPress.com hat am 21. Mai 2026 einen Rückblick auf eine der größten Supply-Chain-Attacken der WordPress-Geschichte veröffentlicht. Im Zentrum steht eine Gruppe von 31 Plugins der ehemaligen Marke Essential Plugin, formerly WP Online Support, mit zusammen Hunderttausenden aktiven Installationen.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Was ist Ihre Meinung? Wer Plugins aus dem offiziellen WordPress.org-Repository installiert, vertraut auf eine etablierte Vertriebskette. Die Essential-Plugin-Attacke führt nüchtern vor Augen, wie verwundbar diese Kette wird, sobald ein bislang vertrauenswürdiger Entwickler unbemerkt den Besitzer wechselt.
Das Wichtigste in Kürze
- Ein unbekannter Käufer übernahm das gesamte Essential-Plugin-Portfolio mit über 30 Plugins aus acht Jahren legitimer Entwicklung
- Rund sechs Monate nach Übernahme wurde Schadcode unter dem Namen wpos-analytics in die Plugins eingespielt
- Anfang April 2026 aktivierten die Angreifer die Hintertür, am 7. April 2026 schloss WordPress.org alle 31 Plugins dauerhaft
- Wer ein betroffenes Plugin nutzt, sieht es zwar im Repository nicht mehr, hat es auf der Site aber weiterhin laufen
Warum Supply-Chain-Angriffe so schwer zu erkennen sind
Der Mechanismus war geduldig aufgesetzt. Ein Käufer erwarb das gesamte Portfolio, hielt es sechs Monate ruhig und schleuste anschließend eine Komponente namens wpos-analytics ein. Der Schadcode lag mehrere Monate inaktiv im Repository und wurde erst Anfang April über einen Remote-Trigger scharf geschaltet. Bis dahin liefen Updates wie gewohnt durch.
Die Reichweite erstreckt sich auf alle Site-Betreiber, die irgendwann ein Plugin der Essential-Familie installiert hatten. Die ursprüngliche Marke WP Online Support war über Jahre bei Bewertungs-, Newsletter- und Kontaktformular-Plugins präsent. Nach der dauerhaften Schließung am 7. April im offiziellen Repository erscheinen die Plugins nicht mehr in Suchergebnissen, bleiben aber auf bestehenden Installationen aktiv. Ein klassisches stilles Problem.
Die Reaktion von WordPress.com hat zwei Hebel. Auf der Plattform selbst wurden betroffene Plugins automatisch deaktiviert. Im offenen WordPress-Ökosystem bleibt die Pflicht beim Site-Betreiber. Wer auf einem normalen WordPress-Hosting ohne automatische Sicherheitsschicht arbeitet, muss die Plugin-Liste selbst gegen die offizielle Liste der 31 betroffenen Slugs prüfen.
Die Essential-Plugin-Attacke zeigt das eigentliche Problem von Open-Source-Vertrieb: Vertrauen lässt sich kaufen, und niemand prüft beim Verkauf, ob die nächste Version noch denselben Werten folgt wie die letzte. Für deutsche Mittelständler bedeutet das, ein simples Plugin-Inventar genügt nicht mehr. Notwendig ist eine laufende Beobachtung, wer welches Plugin gerade pflegt.
— Michael Dobler, Herausgeber Dr. Web
Was Site-Betreiber jetzt tun sollten
Die Bestandsaufnahme hat Priorität. Loggen Sie sich ins Dashboard ein, gleichen Sie installierte Plugins mit der aktuellen Sperrliste ab und deaktivieren Sie jede Übereinstimmung sofort. Das Plugin-Verzeichnis verrät beim Klick auf einen gelöschten Slug, ob er Teil der Supply-Chain-Attacke war.
Die Bereinigung geht über das einfache Abschalten hinaus. Suchen Sie das Verzeichnis wp-content/plugins/ über SFTP und löschen Sie die betroffenen Ordner physisch. Anschließend ein Maleware-Scan, zum Beispiel mit Wordfence oder Sucuri, um zu prüfen, ob die Hintertür weitere Spuren hinterlassen hat. Wer eine Backup-Strategie hat, prüft zusätzlich, ob der jüngste Stand vor Anfang April sauber war. Tipps für die laufende Absicherung finden sich in unserem Beitrag zu Cybersecurity-Grundlagen für KMU.
Die Vorsorge betrifft alle Plugins, nicht nur Essential. Prüfen Sie bei jedem Update, ob der Eigentümer gewechselt hat. Ein Plugin, das jahrelang stabil lief und plötzlich neue Telemetrie oder Tracking-Funktionen einführt, verdient eine Recherche. Tools wie Patchstack oder Wordfence Intelligence verfolgen Eigentümerwechsel und melden verdächtige Code-Veränderungen automatisch.
Wer einen Managed-Hoster nutzt, sollte erfragen, wie der Anbieter auf die Essential-Welle reagiert hat. WordPress.com hat seine Kunden automatisch geschützt. Ein vergleichbares Niveau auf einem klassischen Shared-Hoster ist Sache des Site-Betreibers. Wer hier dauerhaft Zeit sparen will, denkt über einen Wechsel zu einem Anbieter mit aktiver Threat-Intelligence nach.
Studieren? Cybersecurity-Glossar 2026: 99 Begriffe von BSI bis Zero Trust für Entscheider
Mehr Newshunger?
1 Kommentar
Zitat: „… muss die Plugin-Liste selbst gegen die offizielle Liste der 31 betroffenen Slugs prüfen.“
Nehme an, es ist weiterhin diese Liste gemeint: https://www.drweb.de/400-000-wordpress-sites-infiziert/#welche-plugins-sind-betroffen