Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Data-driven survey of open-source Kubernetes security tools from a 2,080-repo corpus — scanning, secrets, policy, runtime, and supply chain integrity.
Am 7. April 2026 hat WordPress.org dauerhaft 31 Plugins des Autors Essential Plugin gesperrt. Jedes einzelne davon war vom selben Angreifer über dieselbe Backdoor kompromittiert worden, die am selben Tag aktiviert wurde. Hunderttausende Websites waren betroffen, viele davon ohne dass die Besitzer jemals bemerkten, dass etwas nicht stimmte.
Essential Plugin begann seine Existenz im Jahr 2015 als WP Online Support, ein in Indien ansässiger WordPress-Entwicklungsbetrieb, der mehr als 30 kostenlose Plugins mit Premium-Upgrades entwickelte. Bis 2024 waren die Einnahmen im Vergleich zum Höchststand um 35 bis 45 Prozent gesunken, woraufhin Gründer Minesh Shah beschloss zu verkaufen. Das gesamte Portfolio wurde auf Flippa, dem Online-Marktplatz für digitale Unternehmen, zum Verkauf angeboten.
Der Käufer wurde lediglich als „Kris“ identifiziert, eine Person mit einem dokumentierten Hintergrund in den Bereichen SEO, Kryptowährungen und Online-Glücksspiel-Marketing. Der Verkaufspreis belief sich auf einen sechsstelligen Betrag. Flippa war mit der Transaktion so zufrieden, dass im Juli 2025 eine entsprechende Fallstudie dazu veröffentlicht wurde.
Am 12. Mai 2025 erschien auf WordPress.org ein neues Konto namens „essentialplugin“ mit SVN-Commit-Zugriff auf jedes Plugin im Portfolio. Niemand bei WordPress.org überprüfte die Änderung. Keine Website-Besitzer erhielten eine Benachrichtigung. Die Schlüssel zu Hunderttausenden von Websites hatten den Besitzer gewechselt, und das Ökosystem bemerkte es nicht.
Der erste Code-Commit des neuen Eigentümers erfolgte am 8. August 2025. Version 2.6.7 der Plugins wurde mit einem Changelog-Eintrag veröffentlicht, der lautete: „Check compatibility with WordPress version 6.8.2.“ Hinter dieser harmlosen Notiz verbarg sich die Injektion von 191 neuen PHP-Zeilen.
Der bösartige Code wurde in class-anylc-admin.php innerhalb des bestehenden wpos-analytics-Moduls platziert, einer Komponente, die jahrelang legitime Analysen bereitgestellt hatte. Das Update fügte eine fetch_ver_info()-Methode hinzu, die den Server des Angreifers unter analytics.essentialplugin.com aufrief, alle zurückgegebenen Daten abrief, diese direkt an PHPs unserialize() weiterleitete und sie anschließend über eine version_info_clean()-Methode ausführte. Dies ist eine klassische PHP-Deserialisierungskette: Der Server sendet ein speziell angefertigtes serialisiertes Objekt, das Plugin packt es aus, und die Gadget-Chain führt beliebigen Code aus.
Auch der Dateiname war bewusst gewählt. class-anylc-admin.php ersetzt den Buchstaben „a“ durch „yl“ in „analytics“, was es erschwert, die Datei auf einen Blick neben der legitimen class-analytics-admin.php zu erkennen.
Die Backdoor blieb acht Monate lang völlig inaktiv. Von August 2025 bis März 2026 lieferte der C2-Server nur normale Antworten. Keine bösartigen Payloads. Kein anomales Verhalten. Die Plugins wurden normal aktualisiert. Automatisierte Sicherheitsscanner hatten keinen Grund, Alarm zu schlagen.
Am 5. April 2026 änderte sich das. Der C2-Server begann, bewaffnete Payloads auszuliefern. Das aktive Injektionsfenster am 6. April dauerte sechs Stunden und 44 Minuten an, zwischen 04:22 und 11:06 UTC, so die forensische Analyse von Anchor Hosting unter Verwendung täglicher restic-Backups.
Während dieses Zeitfensters luden die kompromittierten Plugins eine Datei namens wp-comments-posts.php in die WordPress-Installation herunter. Der Name ahmt die legitime WordPress-Core-Datei wp-comments-post.php nach und unterscheidet sich nur durch einen einzigen Buchstaben. Diese Datei injizierte etwa sechs Kilobyte PHP-Code direkt in wp-config.php, eine der sensibelsten Dateien jeder WordPress-Installation.
Sobald der Code eingebettet war, rief er Spam-Links, Weiterleitungen und gefälschte Seiten vom C2-Server ab und diente diese ausschließlich dem Googlebot aus. Website-Besitzer, die ihre eigenen Seiten aufriefen, sahen nichts Ungewöhnliches. Nur Suchmaschinen-Crawler erhielten die bösartigen Inhalte – eine Cloaking-Technik, die darauf ausgelegt ist, Suchrankings zu manipulieren, während sie für menschliche Besucher unsichtbar bleibt.
Die C2-Infrastruktur war so aufgebaut, dass sie einer Abschaltung widerstand. Anstatt den Command-Server über konventionelles DNS aufzulösen, nutzte der Payload einen Ethereum-Smart-Contract, der über öffentliche Blockchain-RPC-Endpunkte abgefragt wurde. Die Beschlagnahmung einer Domain hätte die Kette nicht unterbrochen; der Angreifer konnte den Contract jederzeit auf eine neue Adresse umleiten.
Die Backdoor registrierte zudem einen nicht authentifizierten WordPress REST API-Endpunkt mit seinem permission_callback auf __return_true, wodurch jeder Besucher die Möglichkeit erhielt, die Deserialisierungskette direkt auszulösen.
Der Angriff wurde von Austin Ginder, dem Gründer von Anchor Hosting, entdeckt, nachdem einer seiner Kunden eine Sicherheitswarnung im WordPress-Dashboard erhalten hatte. Ginders Untersuchung, die am 8. April 2026 veröffentlicht wurde, verfolgte die Injektion über den Backup-Verlauf zurück und identifizierte das gemeinsame wpos-analytics-Modul als Übertragungsvektor.
Die forensische Analyse von Anchor Hosting konnte das exakte Injektionsfenster bestimmen. PatchStack, die WordPress-Sicherheitsplattform, veröffentlichte Schwachstelleneinträge und Mitigationsregeln für alle betroffenen Plugins. WordPress.org reagierte innerhalb von 24 Stunden nach den Meldungen, sperrte am 7. April dauerhaft alle 31 Essential-Plugin-Plugins und veröffentlichte Version 2.6.9.1, welche den Phone-Home-Mechanismus deaktivierte. Dieses Update entfernte jedoch keinen Code, der bereits in wp-config.php injiziert worden war.
Der Essential-Plugin-Angriff nutzte eine Richtlinienlücke im Kern des WordPress-Ökosystems aus. WordPress.org prüft neue Plugin-Einreichungen, bevor sie im Verzeichnis erscheinen. Wenn jedoch ein bestehendes Plugin den Besitzer wechselt – etwa wenn ein Entwickler sein Portfolio an einen Fremden auf Flippa verkauft –, wird keine zusätzliche Code-Überprüfung ausgelöst. Es gibt keine Benachrichtigung über einen „Wechsel der Kontrolle“, die an die Website-Besitzer gesendet wird. Es erfolgt keine automatische tiefgehende Code-Überprüfung, wenn die Commit-Rechte auf eine neue Einheit übertragen werden. Der neue Eigentümer erbt den Ruf des vorherigen Entwicklers, den Commit-Zugriff und das implizite Vertrauen jeder Website, die automatische Updates nutzt.
Dies ist kein neues Muster. Im Jahr 2017 wurde das Plugin Display Widgets für 15.000 $ verkauft und anschließend dazu verwendet, Payday-Loan-Spam zu injizieren. Die Mechanik war identisch: Vertrauen kaufen, warten, bewaffnen. WordPress hat für keinen der beiden Fälle eine strukturelle Lösung implementiert.
Andere Ökosysteme haben auf ähnliche Bedrohungen reagiert. npm führte eine obligatorische Zwei-Faktor-Authentifizierung für Maintainer von Paketen mit hoher Reichweite sowie eine Provenance-Attestierung für Pakete ein. PyPI schlug einen vergleichbaren Weg ein. WordPress, das etwa 43 Prozent aller Websites im Internet antreibt, hat immer noch keine Anforderung zur Code-Signierung für Plugin-Updates, keine obligatorische Zwei-Faktor-Authentifizierung für Entwicklerkonten und keinen Mechanismus zur Prüfung von Eigentumsübertragungen.
Das kompromittierte Portfolio umfasste Countdown Timer Ultimate, Popup Anything on Click, WP Testimonial with Widget, WP Team Showcase and Slider, WP FAQ, SP News and Widget, Blog Designer, Accordion, WP Responsive Recent Post Slider, WP News and Scrolling Widgets sowie etwa 20 weitere Titel. Jedes davon hatte Tausende von aktiven Installationen. Zusammen stellten sie eine ausreichend große Basis dar, um den Angriff als SEO-Spam-Operation kommerziell rentabel zu machen.
Wenn Sie ein Produkt von Essential Plugin verwenden, aktualisieren Sie es sofort. WordPress.org hat ein erzwungenes Sicherheitsupdate (Version 2.6.9.1) veröffentlicht, das die Phone-Home-Funktion deaktiviert. Das Update bereinigt jedoch keinen Code, der bereits in wp-config.php injiziert wurde. Eine manuelle Bereinigung ist weiterhin erforderlich.
Prüfen Sie Ihre WordPress-Installation auf eine Datei namens wp-comments-posts.php im Webroot. Diese gehört dort nicht hin. Löschen Sie sie. Überprüfen Sie wp-config.php auf injizierten PHP-Code, insbesondere im Bereich der require_once-Zeilen. Suchen Sie bei Google nach Ihrer Domain unter Verwendung von site:yourdomain.com und prüfen Sie, ob Spam-Seiten in den Ergebnissen erscheinen. Überprüfen Sie die Eigentumshistorie jedes installierten Plugins, insbesondere bei kleineren Plugins, die den Besitzer gewechselt haben könnten.
Die vollständige technische Analyse von Alina Maria Stan bei TNW deckt die gesamte Zeitlinie und die Angriffskette ab.
Wenn Sie mehr als 15 aktive Plugins haben und die Eigentumsverhältnisse im letzten Jahr nicht überprüft haben, besitzen Sie mit an Sicherheit grenzender Wahrscheinlichkeit eines, dessen Eigentümer gewechselt ist, ohne dass Sie es wussten.