Angreifer sind dazu übergegangen, von der Untersuchung von WordPress-Websites, die von der kritischen Sicherheitslücke CVE-2026-87902 betroffen sind, zu ihrer tatsächlichen Ausnutzung überzugehen, um Dateien auf dem Server zu schreiben und beim Zugriff darauf Shell-Befehle auszuführen. Das Sicherheitsunternehmen Patchstack beobachtete wenige Stunden nach der Veröffentlichung des Patches für WordPress in Version 7.1.2 einen starken Anstieg der Aktivitäten.
Von der Aufklärung zur Ausführung der Payload
Der anfängliche Angriffsverkehr, der offenbar der Identifizierung verwundbarer Websites diente, begann weniger als fünf Stunden nach der Veröffentlichung des Patches. Laut Patchstack wurden die ersten bösartigen Anfragen am 22. September um 17:44 Uhr UTC von einer kleinen Gruppe von IP-Adressen registriert, die mehrere geschützte Websites angriff.
Am folgenden Tag nahm der mit der Sicherheitslücke verbundene Datenverkehr um das Zehnfache zu und umfasste eine Phase, in der Dateien auf die Festplatte geschrieben wurden. Einige Anfragen versuchten offenbar, gewöhnliche Dateien aus dem WordPress-Kern einzubinden, um ausnutzbare Websites zu identifizieren, bevor zum Senden bösartiger Payloads übergegangen wurde.
Art der Sicherheitslücke und Ausnutzungsbedingungen
Der Sicherheitsforscher Robert Ressl entdeckte einen nicht dokumentierten Fehler im Zusammenhang mit der Umgehung von Pfaden, der unter bestimmten Umständen zur Remote-Befehlsausführung führen kann. Die Sicherheitslücke ermöglicht es einem nicht authentifizierten Angreifer, die Funktion get_page_template() dazu zu bringen, eine lokal lesbare PHP-Datei außerhalb der Verzeichnisse des aktiven Themes einzubinden. Das WordPress-Sicherheitsteam bewertete ihren Schweregrad mit 9,2 von 10.
Für die Ausführung von Befehlen müssen bestimmte Bedingungen erfüllt sein. Dazu gehören ein Verzeichnis der obersten Ebene, dessen Name im aktiven übergeordneten oder untergeordneten Theme mit page- beginnt, sowie eine lokal lesbare PHP-Datei, auf die das Webserver-Konto zugreifen kann. Die offizielle Warnung nennt pearcmd.php als Beispiel, wenn die Einstellung register_argc_argv aktiviert ist.
Die Warnung bestätigte außerdem, dass das offizielle, mit Docker verwendete PHP-Image betroffen ist, ebenso wie die Standardeinstellung in cPanel bei Verwendung einer PHP-Version vor 8.5.
Was tun die Angreifer derzeit?
Patchstack beobachtete Anfragen, die das Tool pearcmd nutzten, um von der Funktion config-show zu config-create überzugehen. Dies ermöglicht das Schreiben einer Datei an einem vom Angreifer festgelegten Ort mit von ihm kontrolliertem Inhalt. Bei einigen Dateien bestand der Zweck offenbar lediglich darin, eine Markierung zu setzen, die die Ausnutzbarkeit des Servers bestätigt. Die Forscher des Unternehmens beobachteten jedoch auch Dateien mit einem kurzen Tag, das beim Öffnen der Datei einen Shell-Befehl ausführt.
Die beobachteten Dateien wurden in den Verzeichnissen /tmp und /var/tmp abgelegt und trugen Namen wie wp-pear-rce-flag.php, poc87902.php, luci_<random>.php und zeta_<random>.php. Das Unternehmen veröffentlichte keine vollständige praktische Anfrage, erklärte jedoch, dass die Versuche doppelt codierte Pfadumgehungssequenzen innerhalb von pagename zusammen mit einem gültigen Wert für page_id verwenden.
Was sollte getan werden?
WordPress veröffentlichte Version 7.1.2 zur Behebung von CVE-2026-87902. Aufgrund des Schweregrads der Sicherheitslücke wurde der Fix außerdem in die Zweige bis einschließlich Version 4.7 zurückportiert. Versionen vor 4.6 werden dafür keinen Fix erhalten.
Website-Administratoren sollten so bald wie möglich auf Version 7.1.2 aktualisieren und anschließend die Protokolle auf verdächtige Anfragen sowie ungewöhnliche PHP-Dateien in den Verzeichnissen /tmp und /var/tmp überprüfen. Patchstack nannte außerdem Adressen, die zu Sperrlisten hinzugefügt werden können: 169.58.48.193, 169.58.48.195 und 2001:df1:e8c0::106b.
Die Bedeutung dieser Entwicklung liegt darin, dass das Zeitfenster vom Ausspähen bis zur tatsächlichen Ausnutzung ungefähr einen Tag nicht überschritten hat. Für Websites, deren Aktualisierung nicht nachgewiesen wurde, reicht es daher nicht aus, sich allein auf die Überwachung zu verlassen. Die Möglichkeit zur Befehlsausführung bleibt an die besonderen Bedingungen der Themes und PHP-Dateien sowie an die Umgebungseinstellungen gebunden, doch die beobachteten Aktivitäten belegen, dass die Sicherheitslücke keine rein theoretische Gefahr mehr ist.