WordPress-Lücke wird aktiv attackiert: Was Firmen jetzt tun müssen

Eine Lücke, die keine Wartezeit lässt

Normalerweise vergehen zwischen der Veröffentlichung eines Sicherheitsupdates und den ersten echten Angriffen Tage oder Wochen. Diesmal nicht. Wie heise Security berichtet, haben Angreifer bereits wenige Stunden nach dem WordPress-Update vom Dienstag damit begonnen, die geschlossene kritische Lücke zu sondieren – und seit Mittwoch laufen gezielte Angriffe.

Für Unternehmen mit einer WordPress-Website heißt das: Das Zeitfenster, in dem ein Update noch vorbeugend wirkt, ist hier praktisch auf null geschrumpft. Wer jetzt noch auf einer verwundbaren Version läuft, muss davon ausgehen, dass automatisierte Scans seine Installation längst gefunden haben oder in Kürze finden werden.

Was die Lücke technisch ermöglicht

Die Schwachstelle mit der Kennung CVE-2026-87902 wurde von den Sicherheitsforschern von Patchstack mit einem CVSS-Wert von 9,2 als kritisch eingestuft. Angreifer können ohne vorherige Anmeldung über eine sogenannte Path-Traversal-Schwachstelle lokale PHP-Dateien auf dem Server einbinden. Unter bestimmten Voraussetzungen – abhängig vom Server und vom aktiven Theme – lässt sich das zum Ausführen von Schadcode missbrauchen.

Betroffen sind laut dem Bericht alle WordPress-Versionen von 4.7.0 bis einschließlich 7.1.1. Das ist eine enorme Bandbreite: Praktisch jede WordPress-Installation, die in den letzten Jahren aufgesetzt wurde und nicht aktuell gepatcht ist, zählt dazu.

Die Angriffe laufen dabei mehrstufig ab. Zunächst testen die Angreifer mit Inklusionsversuchen auf gewöhnliche Core-Dateien, ob eine Instanz verwundbar ist. Danach greifen sie auf die Datei „pearcmd.php“ zu und nutzen deren Befehl „config-create“, um eigene PHP-Dateien auf dem Server abzulegen. Beobachtet wurden Dateien mit Namen wie „wp-pear-rce-flag.php“, „poc87902.php“ oder „luci_.php“ in den Verzeichnissen /tmp und /var/tmp.

Warum das auch für kleine Firmenwebsites gilt

Ein verbreiteter Irrtum: „Unsere Website ist doch nur eine Visitenkarte, die interessiert niemanden.“ Das greift hier zu kurz. Die beobachteten Angriffe laufen automatisiert und flächendeckend. Der Traffic auf die Schwachstelle ist laut Patchstack seit dem ersten Abend auf mehr als das Zehnfache angestiegen. Zudem kursieren öffentlicher Proof-of-Concept-Code und eine Vorlage für den Schwachstellenscanner Nuclei – Angriffe sind damit auch für Akteure ohne tiefes Fachwissen sehr einfach möglich.

Dass die bislang beobachteten Dateien in /tmp abgelegt wurden – einem Ordner, der üblicherweise nicht aus dem Netz erreichbar ist –, ist dabei kein Trost. Die Forscher werten das eher als Beleg erfolgreicher Codeausführung denn als persistente Hintertür. Aber: Kompromittiert ist der Host damit vollständig. Auf demselben Weg könnten Angreifer Dateien auch an aus dem Netz erreichbaren Orten ablegen. Was im Einzelfall bereits passiert ist, lässt sich ohne Prüfung nicht sagen.

Was Sie jetzt konkret tun sollten

Erstens: Version prüfen und aktualisieren. Als fehlerbereinigte Fassungen stehen WordPress 7.1.2, 7.0.6, 6.9.9 und 6.8.10 zur Verfügung, dazu Backports für alle älteren Zweige bis hinunter zu 4.7.37. Wenn automatische Updates aktiv sind, spielt WordPress den Fix selbst ein – prüfen sollten Sie das Ergebnis trotzdem. Ob Ihre Installation automatische Updates tatsächlich ausführt, ist eine Frage, die Sie sich nicht mit „vermutlich schon“ beantworten sollten.

Zweitens: Auf Kompromittierung prüfen. Das Update allein reicht nicht, wenn der Angriff bereits erfolgt ist – es schließt die Tür, holt aber niemanden aus dem Haus, der schon drin ist. Die Patchstack-Analyse enthält laut dem Bericht Indicators of Compromise, also konkrete Hinweise auf erfolgreiche Angriffe. Wer die technische Möglichkeit hat, sollte die Server-Verzeichnisse /tmp und /var/tmp sowie das Webverzeichnis auf verdächtige PHP-Dateien untersuchen. Fehlt Ihnen dafür der Zugriff oder das Know-how, ist das ein klarer Fall für Ihren Webdienstleister oder Hoster.

Drittens: Verantwortlichkeit klären. Gerade in Unternehmen mit 10 bis 100 Mitarbeitern ist die Website oft ein Nebenprodukt – irgendwann von einer Agentur gebaut, seitdem betreut von niemandem so richtig. Jetzt ist der Moment, schriftlich festzuhalten: Wer spielt Updates ein? Wer überwacht, ob sie erfolgreich waren? Wer prüft im Verdachtsfall auf Kompromittierung? Wenn auf diese Fragen keine klare Antwort existiert, haben Sie ein strukturelles Problem, das über diese eine Lücke hinausreicht.

Viertens: Backup-Lage klären. Sollte sich herausstellen, dass Ihre Instanz kompromittiert wurde, ist ein sauberes Backup aus der Zeit vor dem Angriff oft der schnellste Weg zurück zu einem vertrauenswürdigen Stand. Ob Ihre Backups aktuell, vollständig und – wichtig – wiederherstellbar sind, sollten Sie wissen, bevor Sie sie brauchen.

Was noch unklar ist

Einige Fragen kann die Meldung nicht beantworten, und es wäre unseriös, sie zu erfinden: Wie viele Installationen bereits erfolgreich angegriffen wurden, ist nicht bekannt. Ob die Angreifer die abgelegten Dateien bereits für Folgeaktionen nutzen – etwa Spam-Versand, Datenklau oder als Sprungbrett ins interne Netz –, bleibt offen. Und ob Ihr konkretes Theme zu den Voraussetzungen passt, unter denen die Lücke zur Codeausführung führt, lässt sich nur im Einzelfall prüfen. Auch das spricht dafür, die Instanz nicht nur zu patchen, sondern auf Indikatoren zu untersuchen.

Fazit: Stunden zählen, nicht Tage

Diese Lücke ist ein Beleg dafür, wie sehr sich das Angriffstempo beschleunigt hat. Zwischen Patch und massenhafter Ausnutzung lagen hier Stunden. Für Unternehmen bedeutet das: Der klassische Rhythmus „wir aktualisieren einmal im Quartal“ ist für ein so verbreitetes System wie WordPress nicht mehr tragfähig. Aktivieren Sie automatische Updates, wo es geht, und stellen Sie sicher, dass jemand die Verantwortung für Ihre Website trägt – mit Namen, nicht als Nebenbei-Aufgabe. Und wenn Sie unsicher sind, ob Ihre Installation betroffen oder bereits kompromittiert ist: Fragen Sie jetzt Ihren Webdienstleister oder Hoster, nicht nächste Woche.

Dieser Artikel wurde KI-unterstützt auf Basis einer Fachmeldung erstellt und vor der Veröffentlichung geprüft.