Am 14. September konnten Nutzer des kostenpflichtigen Plugins Admin Menu Editor Pro ein ganz normales Update auf Version 2.35 erhalten. Es kam direkt vom offiziellen Server des Herstellers. Nur enthielt das Paket die Datei includes/wp-user-consent.php, die auf der Website eine Webshell installierte – also einen Mechanismus, über den sich aus der Ferne Befehle auf dem Server ausführen lassen.

Der Hersteller entfernte das manipulierte Paket und veröffentlichte noch am selben Tag eine saubere Version 2.36. Wenige Stunden später war auch sie verändert worden. Spätestens da war klar, dass das Problem nicht bei einem übernommenen Konto im Admin-Bereich oder einer einzelnen Datei endete. Die Angreifer hatten sehr wahrscheinlich deutlich tieferen Zugriff auf die Infrastruktur.

Das war ein Supply-Chain-Angriff, keine gewöhnliche WordPress-Schwachstelle

Bei einer klassischen Schwachstelle sucht ein Angreifer nach einem Fehler im Code, der bereits auf der Website installiert ist. Hier wurde zuerst der Ort kompromittiert, dem Website-Betreiber vertrauen: der Server, über den die offiziellen Updates verteilt werden. Erst danach wurde über genau diese vertrauenswürdige Quelle eine manipulierte Plugin-Version ausgeliefert.

WebsiteGarage / Leistungen

Entdecke unsere Leistungen.

Genau das ist ein Supply-Chain-Angriff. Niemand muss einen Administrator dazu bringen, eine Datei von irgendeiner dubiosen Domain herunterzuladen. Kontrolliert der Angreifer den echten Update-Kanal, sieht das bösartige Paket aus wie ein ganz normales Update.

Version 2.35: Website als kompromittiert behandeln. Auch 2.36 ist keine Entwarnung

Die Mitteilung des Herstellers ist eindeutig. Wurde Version 2.35 am 14. September installiert, sollte die Website als kompromittiert behandelt werden. Auch bei Version 2.36 muss von einer möglichen Kompromittierung ausgegangen werden, besonders wenn sie nach 19:00 UTC heruntergeladen wurde. Version 2.34 gilt nach aktuellem Kenntnisstand als sauber.

Für die erste Phase des Vorfalls schätzte der Hersteller zunächst rund 230 betroffene Kunden, von denen viele mehr als eine Website betreiben. Später kamen etwa 300 weitere Kunden hinzu, die im zweiten Zeitfenster potenziell betroffen waren. Das sind Kundenzahlen, keine bestätigte Zahl infizierter Websites.

Was der Schadcode gemacht hat

Der wichtigste Bestandteil war die Webshell. Praktisch bedeutet das: Auf einer kompromittierten Website konnte Code ausgeführt werden. Der Hersteller warnt deshalb ausdrücklich davor, nur nach einer einzelnen verdächtigen Datei zu suchen. Man sollte davon ausgehen, dass ein Angreifer vollständige Kontrolle über die Website gehabt haben könnte.

Berichte von Nutzern zeigten weitere Spuren: ein Verzeichnis /wp-content/object-cache mit einem zufällig benannten PHP-Skript, Datenbankeinträge, die mit wp_ocache oder _wp_ocache_ beginnen, ein verstecktes Benutzerkonto, dessen Login mit wp_ begann, verdächtige MU-Plugins und einen WP-Cron-Job namens _wp_cconsent_tick.

Der Hersteller weist darauf hin, dass ein solches verstecktes Benutzerkonto in der normalen WordPress-Benutzerliste möglicherweise gar nicht auftaucht, direkt in der Tabelle wp_users aber sichtbar ist. Ein kurzer Blick in den Menüpunkt „Benutzer“ reicht also unter Umständen nicht.

Die erste Bereinigung half nicht, weil der Angreifer noch im System war

Nachdem Version 2.35 entdeckt worden war, entfernte der Hersteller sie und veröffentlichte 2.36. Noch am selben Tag wurde ein weiterer Einbruch festgestellt, und auch Version 2.36 war manipuliert worden. Die Versuche, den Angriff zu stoppen, schlugen fehl. Schließlich wurde der Server abgeschaltet.

Am 17. September kam eine neue Spur hinzu: möglicherweise hatten die Angreifer über eine Schwachstelle in einem veralteten Linux-Kernel Root-Rechte erlangt. Sollte sich das bestätigen, würde es gut erklären, warum das Bereinigen der Anwendung und der Austausch eines Pakets nicht ausreichten. Der Angreifer könnte sich auf einer tieferen Systemebene festgesetzt haben, als die Bereinigung überhaupt erreichte.

Was sollte ein Website-Betreiber mit diesem Plugin jetzt tun?

Wenn Version 2.35 vom 14. September auf der Website installiert war, nennt der Hersteller als sicherste Variante die Wiederherstellung aus einem Backup von vor dem 14. September. Auch bei Version 2.36 sollte niemand davon ausgehen, dass allein die Versionsnummer eine saubere Installation garantiert.

Empfohlen werden außerdem: die verdächtige Version entfernen, nach den beschriebenen Artefakten suchen, die Passwörter der WordPress-Benutzer ändern, neue Keys und Salts in wp-config.php erzeugen und sämtliche Zugangsdaten austauschen, die die Website verwendet oder speichert – für Datenbank, SFTP oder FTP, Hosting-Panel und API-Keys. Dazu kommen ein vollständiger Scan und die Prüfung aller Dateien, die seit dem 14. September verändert wurden.

Der Hersteller selbst betont, dass das vollständige Bild des Payloads noch nicht bekannt ist und einzelne Maßnahmen daher möglicherweise nicht ausreichen. Bei einem Vorfall dieser Art ist „Datei gelöscht, alles sauber“ eher Hoffnung als Incident-Response-Plan.

WebsiteGarage sagt

Automatische Updates sind wichtig. Updates direkt vom Hersteller sind ebenfalls wichtig. Dieser Vorfall ist kein Argument dafür, sie abzuschalten und wieder einmal pro Quartal manuell auf „Aktualisieren“ zu klicken. Er zeigt etwas anderes: Updates sind ein Baustein der Sicherheitsstrategie, nicht die gesamte Sicherheitsstrategie.

Wird der Hersteller selbst kompromittiert, kann aus dem offiziellen Update-Kanal selbst ein Infektionsweg werden. Genau deshalb sind Backups außerhalb des Servers, Änderungsmonitoring, eine funktionierende Wiederherstellung, begrenzte Berechtigungen und ein klarer Incident-Response-Prozess sinnvoll. Ohne diese Dinge wird WordPress-Sicherheit schnell zum Ritual: alles grün, alles aktuell, also wird schon alles gut sein. Die entscheidende Frage ist nur: Wenn beim nächsten Mal jemand auf „Aktualisieren“ klickt – schaut dann auch jemand nach, warum dieses Update da ist und ob danach zusätzliche Schritte nötig sind? Wie man sieht, lohnt sich der Blick in die Versionshinweise.

Die interessanteste Lektion ist noch einfacher. Nach der ersten Manipulation stellte der Hersteller eine saubere Version bereit. Der Eindringling manipulierte auch diese wieder. Wenn die Ursache einer Kompromittierung nicht beseitigt wird, kann die frisch bereinigte Datei einfach das nächste Ziel sein.