Anfragen an den Batch-Endpunkt der WordPress REST API haben sich auf unserer Infrastruktur mehr als verdreifacht
In der Woche ab dem 26. Oktober stieg die Zahl der Quellen, die auf unserer Infrastruktur nach dem Batch-Endpunkt der WordPress REST API fragten, auf das 3.3-Fache ihres bisherigen Wochendurchschnitts. Dieser Endpunkt ist der Einstiegspunkt der Schwachstellenkette wp2shell. Zudem suchten Scanner häufiger nach Backups, Debug-Seiten und Anwendungsinterna.
291 Intercept ist unser wöchentlicher Bericht darüber, worauf es automatisierte Scanner auf unserer eigenen Infrastruktur abgesehen hatten, damit Sie Ihre Systeme auf dieselben Punkte prüfen können. Jede Ausgabe behandelt eine Woche, die mindestens sieben Tage zurückliegt.
Die deutlichste Veränderung auf unserer Infrastruktur in der Woche ab dem 26. Oktober war ein sprunghafter Anstieg der Anfragen nach einer bestimmten WordPress-Adresse: /wp-json/batch/v1. Rund 40 Quellen fragten sie ab, das 3.3-Fache ihres Wochendurchschnitts der drei Vorwochen. An diesem Endpunkt setzt wp2shell an, eine Kette aus zwei Schwachstellen im WordPress-Kern, über die ein Angreifer ohne Anmeldung Code auf einer Website ausführen kann.
Insgesamt war es eine lebhaftere Woche: Rund 620 Quellen tasteten unsere aus dem Internet erreichbare Infrastruktur ab, 10% mehr als im Durchschnitt der drei Vorwochen. WordPress blieb das Hauptziel: 66% der Quellen hatten es auf WordPress-Anmeldungen, XML-RPC oder Plugin-Pfade abgesehen, ein Plus von 20%. Außerdem fragten Scanner häufiger nach Teilen einer Anwendung, die eigentlich nicht öffentlich zugänglich sein sollten.
Was wp2shell ist
/wp-json/ ist die Wurzel der REST API von WordPress, und /wp-json/batch/v1 ist ihr Batch-Prozessor, der mehrere API-Anfragen gebündelt verarbeitet. Laut Rapid7 verbindet wp2shell zwei Schwachstellen. CVE-2026-63030 ist ein Logikfehler in diesem Batch-Prozessor, CVE-2026-60137 eine SQL-Injection im Posts-Endpunkt. In Kombination ermöglichen sie es jemandem ohne Konto, Code auf WordPress 6.9.0 bis 6.9.4 sowie 7.0.0 bis 7.0.1 auszuführen.
Die Schwachstelle wurde am 17. Juli 2026 veröffentlicht, und laut Rapid7 nahm die CISA sie am 21. Juli in ihren Katalog Known Exploited Vulnerabilities auf. Behoben ist sie in den Versionen 6.9.5, 7.0.2 und 7.1 Beta 2.
Warum nach einer Lücke suchen, für die es längst einen Fix gibt? Scanner sind nicht darauf angewiesen, dass jede Website verwundbar ist; es genügt, wenn einige es sind. Eine Anfrage kostet sie fast nichts, und jede Website, auf der noch eine betroffene Version läuft, ist einen zweiten Besuch wert.
Die bekannte Seite des WordPress-Scannens
Ein koordiniertes Toolkit aus rund 20 Quellen in einigen wenigen Ländern arbeitete dieselbe Liste von etwa zehn Pfaden ab. Es fragte dieselbe Datei unter vielen Verzeichnisnamen ab, etwa /wp/wp-includes/wlwmanifest.xml, /shop/wp-includes/wlwmanifest.xml und /wordpress/wp-includes/wlwmanifest.xml, dazu /xmlrpc.php.
wlwmanifest.xml ist das Manifest für Windows Live Writer, das bei Standardinstallationen von WordPress vorhanden ist. Die Abfrage unter gängigen Verzeichnisnamen ist eine Methode, WordPress-Websites aufzuspüren, bevor Exploits für Plugins oder Themes ausprobiert werden. XML-RPC ist der nächste Schritt: Forscher stellten 2015 fest, dass die dortige Methode system.multicall es einem Angreifer ermöglicht, Hunderte Passwörter in einer einzigen Anfrage durchzuprobieren.
Überbleibsel und Interna
Im Vergleich zu den drei Vorwochen stieg die Zahl der Quellen, die nach Backup- und Dump-Dateien suchten, um 73%, die Zahl derer, die Anwendungsinterna wie den Spring Boot Actuator ins Visier nahmen, um 63%, und die Zahl derer, die Diagnoseseiten wie /phpinfo.php und /info.php abriefen, um 52%. Da auch die Gesamtzahl der Quellen wuchs, verschoben sich ihre Anteile weniger stark: Diagnoseseiten stiegen von durchschnittlich 15% aller Quellen auf 21%. Das folgende Diagramm zeigt sechs Kategorien dieser Woche, jeweils mit ihrem Anteil an den Quellen in dieser Woche im Vergleich zum Durchschnitt der drei Vorwochen.
Anteil aller verschiedenen Quellen, die es auf das jeweilige Ziel abgesehen hatten, in Prozent. Eine Quelle kann mehrere Ziele ins Visier nehmen, daher ergeben die Anteile zusammen mehr als 100 %.
| Diese Woche | Durchschnitt der vorherigen 3 Wochen | |
|---|---|---|
| Backups und Datenbankdumps | 12 % | 9 % |
| Verwaltungsendpunkte von Anwendungen | 13 % | 9 % |
| Seiten für Debugging und Diagnose | 21 % | 15 % |
| Anmeldeseiten und Dateien von WordPress | 66 % | 61 % |
| Offengelegter Quellcode (Git, SVN) | 29 % | 24 % |
| Secrets und Konfigurationsdateien | 33 % | 33 % |
/actuator/env zog rund 40 Quellen an, das 2.4-Fache des bisherigen Durchschnitts. Bei Spring Boot zeigt dieser Endpunkt die Konfigurationseigenschaften der Anwendung. Laut der Dokumentation von Spring ist standardmäßig nur health über HTTP erreichbar, und env-Werte werden standardmäßig maskiert. Geben Entwickler den Endpunkt jedoch frei, ohne den Zugriff einzuschränken, können Zugangsdaten, API-Schlüssel und interne Einstellungen abfließen. /wp-config.php.bak, ein vergessenes Backup der WordPress-Konfiguration, verdoppelte sich auf rund 40 Quellen.
Ein zweites Toolkit aus rund 20 Quellen kombinierte diese Interessen in einem einzigen Durchlauf: /.env, /.git/config, /info.php, /config.json, /server-status und /debug/default/view. Der letzte Pfad gehört zum Debugger von Yii 2, der Sitzungsdaten, Umgebungsvariablen und Datenbankabfragen anzeigt. Das Handbuch von Yii besagt, dass er normalerweise nur über localhost erreichbar ist, doch CVE-2026-103475, veröffentlicht am 30. September, betrifft yii2-starter-kit bis einschließlich 4.2.0, dessen Standardkonfiguration ihn für alle IP-Adressen öffnet.
Nachtrag zur letzten Woche
In unserer letzten Ausgabe haben wir festgestellt, dass mehr Scanner nach .env-Dateien in Unterverzeichnissen suchten. Das hielt an. /v2/.env und /old/.env zogen jeweils rund 60 Quellen an, etwa doppelt so viele wie im bisherigen Durchschnitt; /production/.env kam auf 50 und /storage/.env auf 40. Insgesamt hatten es 200 Quellen auf Geheimnis- und Konfigurationsdateien abgesehen, ein Plus von 16% und damit etwa im Gleichschritt mit dem Anstieg der Quellen insgesamt, sodass ihr Anteil bei 33% blieb. Zur Einordnung: Forscher meldeten im Februar 12,088,677 IP-Adressen, die öffentlich zugängliche Dateien im Stil von .env auslieferten.
Die Git-Abfragen, mit denen wir letzte Woche aufgemacht hatten, gingen anteilig zurück, blieben aber über ihrem früheren Niveau. Insgesamt suchten 170 Quellen nach Quellcode-Repositorys, 20% mehr als im Dreiwochendurchschnitt, auch wenn ihr Anteil an allen Quellen von 37% auf 29% sank.
Wer da anfragte
Mehr als die Hälfte der Quellen (55%) stammte aus Cloud- und Hosting-Netzen, wobei DigitalOcean und Google Cloud auf jeweils 20% kamen, und 85% aller Quellen tauchten nur an einem einzigen Tag auf. Die meisten versuchten zudem, wie Menschen zu wirken: 82% sendeten Kennungen, die sich als gewöhnliche Browser ausgaben, doch 85% verhielten sich wie Automatisierung. Die Tarnung ist also dünn.
Was abgeflaut ist
Anfragen nach /wp-content/plugins/hellopress/wp_filemanager.php, die im Schnitt auf rund 20 Quellen pro Woche kamen, gingen fast auf null zurück, ein Minus von 79%. Ob die Scanner weitergezogen sind, lässt sich noch nicht sagen. Cloud-Schlüsseldateien wie /service-account.json blieben mit rund 70 Quellen weitgehend stabil.
Was zu tun ist
- Prüfen Sie Ihre WordPress-Version. Liegt sie zwischen 6.9.0 und 6.9.4 oder zwischen 7.0.0 und 7.0.1, aktualisieren Sie jetzt auf 6.9.5 oder 7.0.2.
- Halten Sie .env-Dateien vollständig aus dem öffentlichen Verzeichnis heraus, auch bei alten Releases und versionierten Unterverzeichnissen. Sicher aufgehoben sind sie eine Ebene oberhalb des Web-Roots.
- Löschen Sie Backups und Dumps wie
/database.sqloder/wp-config.php.bakvon allem, was ein Browser erreichen kann. - Schotten Sie Interna ab. Beschränken Sie den Zugriff auf die Actuator-Endpunkte von Spring Boot und lassen Sie die env-Maskierung aktiviert, entfernen Sie phpinfo-Testseiten und beschränken Sie den Yii-Debugger auf localhost.
- Deaktivieren Sie XML-RPC, wenn nichts auf Ihrer Website es benötigt.
Über diese Beobachtungen
Dieser Bericht wird von 291 Heat Seeker One erstellt, dem Sicherheitsüberwachungssystem der 291 Group, das auf 291 Crossband läuft, unserer proprietären Plattform für Security Operations. Er umfasst ausschließlich Datenverkehr zur aus dem Internet erreichbaren Infrastruktur der 291 Group.
Die Zahlen sind gerundet, Anteile und Veränderungen werden anhand der Anzahl unterschiedlicher Quellen gemessen, nicht anhand der Anfragen, und berücksichtigt werden nur Muster, die von mindestens 20 unterschiedlichen Quellen ausgingen. Die Länderangaben beziehen sich auf den Standort der Server, nicht zwingend auf den Aufenthaltsort der Betreiber. Die Netzwerkart ergibt sich aus dem Betreiber des jeweiligen Netzes; namentlich genannt werden nur große, bekannte Anbieter.