Die Remote-Code-Execution-Schwachstelle CVE-2025-24893 in XWiki wird aktuell massiv durch das Botnetz RondoDox angegriffen. Die Lücke ist bereits im Known Exploited Vulnerabilities (KEV)-Katalog der US‑Behörde CISA gelistet, was auf bestätigte Ausnutzung in freier Wildbahn hinweist. Seit Anfang November steigen die beobachteten Exploit-Versuche deutlich, ein Indikator dafür, dass Cyberkriminelle funktionierende Exploits rasch operationalisiert haben.
RondoDox-Botnetz: Neue Kampagne gegen Server- und IoT-Infrastrukturen
RondoDox wurde laut Analysen von Fortinet im Sommer 2025 erstmals umfassend beobachtet. Hinter dem Botnetz steht eine vergleichsweise neue, auf Skalierung ausgerichtete Gruppe, die Internet-verbundene Geräte und Server in grosser Zahl kompromittiert, um eine verteilte Angriffsinfrastruktur aufzubauen.
Forschende von Trend Micro berichten, dass aktuelle RondoDox-Varianten ein breites Spektrum an Zielen anvisieren – von digitalen und Netzwerk-Videorekordern über Videoüberwachungssysteme bis hin zu Webservern. Zur Infektion nutzt die Gruppe Dutzende Schwachstellen, darunter auch solche, die zuvor auf Wettbewerben wie Pwn2Own demonstriert wurden. Dieses Vorgehen entspricht etablierten Mustern moderner Botnetze, die schnell bekannte Proof-of-Concept-Exploits in breit ausgerollte Kampagnen überführen.
CVE-2025-24893: Kritische Remote-Code-Execution in der Wiki-Plattform XWiki
XWiki ist eine weitverbreitete Open-Source-Wiki-Plattform, die Unternehmen als zentrales System für Wissensmanagement, Projektdokumentation und Prozesshandbücher nutzen. Durch umfangreiche Integrationsmöglichkeiten hängt XWiki häufig direkt an kritischen Geschäftsprozessen, etwa an Ticketing-, CI/CD- oder Identitätsmanagementsystemen – ein attraktives Ziel für Angreifer.
Die Schwachstelle CVE-2025-24893 betrifft XWiki-Versionen unterhalb von 15.10.11 und 16.4.1. Sie ermöglicht Remote Code Execution (RCE), also die Ausführung beliebigen Codes aus der Ferne. In der Praxis erhält ein Angreifer damit die Möglichkeit, Kommandos auf dem XWiki-Server auszuführen – meist mit den Rechten des XWiki-Dienstkontos, in bestimmten Konfigurationen jedoch mit weitreichend erhöhten Privilegien. Aus Sicht gängiger Risikobewertungen entspricht dies einer kritischen Sicherheitslücke mit potenziell vollständiger Systemkompromittierung.
Technische Analyse: Groovy-Injektion über den SolrSearch-Endpoint
Exploitation über präparierte HTTP-GET-Requests
Laut VulnCheck setzen die Betreiber von RondoDox seit dem 3. November 2025 auf speziell aufgebaute HTTP-GET-Anfragen gegen verwundbare XWiki-Installationen. Im Fokus steht der Endpoint SolrSearch, der im Rahmen der Suchfunktionalität die Ausführung von Groovy-Code unterstützt. Fehlerhafte Eingabevalidierung eröffnet hier die Möglichkeit einer Groovy-Injektion.
Der bösartige Request enthält einen Base64-codierten Groovy-Schnipsel, der serverseitig dekodiert und unmittelbar ausgeführt wird. Dieser Script-Loader lädt wiederum ein Shell-Script von einem entfernten Server nach, das für die eigentliche Installation der RondoDox-Malware verantwortlich ist. Nach erfolgreicher Ausführung wird der XWiki-Server unbemerkt zu einem Botnet-Knoten, der Befehle von den Command-and-Control-Systemen (C2) der Angreifer empfängt.
Kryptomining und Reverse-Shells auf kompromittierten Servern
Analysen zeigen, dass RondoDox kompromittierte XWiki-Systeme nicht nur in das Botnetz integriert, sondern zusätzlich Crypto-Miner ausrollt. Diese nutzen die CPU- und Speicherressourcen der Server zur Erzeugung von Kryptowährungen. Typische Indikatoren sind stark erhöhte Prozessorlast, unerklärlicher Ressourcenverbrauch und spürbare Performanceeinbussen geschäftskritischer Anwendungen.
In einzelnen Fällen wurden zudem Versuche registriert, Reverse-Shells zu etablieren. Dabei baut der kompromittierte Server selbst eine Verbindung zu einem Angreiferhost auf und stellt eine interaktive Kommandozeile bereit. Diese Technik ermöglicht lateral movement innerhalb des Netzwerks, die Ausweitung der Kompromittierung sowie das Aufrechterhalten von Persistenz – selbst dann, wenn einzelne Malware-Komponenten entdeckt und entfernt werden.
Massenscans auf XWiki und Groovy-Injektionen durch verschiedene Akteure
Die Ausnutzung von CVE-2025-24893 ist nicht auf RondoDox beschränkt. Nach Beobachtungen von VulnCheck laufen im Internet breit angelegte Massenscans gegen XWiki-Instanzen, unter anderem mit dem beliebten Schwachstellen-Scanner Nuclei. Angreifer setzen Groovy-Injektions-Templates ein und testen einfache Kommandos wie cat /etc/passwd, um die Verwundbarkeit zu verifizieren und das Kontrollniveau zu bewerten.
Darüber hinaus werden vermehrt OAST-Scans (Out-of-Band Application Security Testing) registriert. Hierbei prüft der Angreifer nicht nur die HTTP-Antwort, sondern auch, ob der Zielserver externe Interaktionen auslöst, etwa DNS- oder HTTP-Anfragen zu einer kontrollierten Domain. Solche Techniken werden gleichermaßen von Angreifern, Red-Teams und Sicherheitsforschenden genutzt und zeigen, dass die Schwachstelle bereits fest in gängige Angriffs- und Testwerkzeuge integriert ist.
Risiken für Unternehmen und priorisierte Schutzmassnahmen
Die Kombination aus kritischer RCE-Schwachstelle in XWiki und automatisierter Ausnutzung durch ein Botnetz erzeugt erhebliche Risiken. Neben dem unautorisierten Zugriff auf interne Dokumentation und Zugangsdaten droht die Zweckentfremdung der Unternehmensinfrastruktur für DDoS-Angriffe, Spam-Kampagnen, Krypto-Mining oder den Weiterverkauf von Zugangsdaten im Untergrund. Branchenberichte wie der Verizon Data Breach Investigations Report und Studien von ENISA weisen seit Jahren darauf hin, dass ungepatchte Remote-Exploits zu den häufigsten Initialvektoren schwerwiegender Vorfälle gehören.
Administratoren von XWiki sollten folgende Massnahmen mit höchster Priorität umsetzen:
- Patch-Management: XWiki umgehend mindestens auf Version 15.10.11 oder 16.4.1 aktualisieren, in denen CVE-2025-24893 behoben wurde.
- Angriffsfläche reduzieren: Prüfen, ob XWiki direkt aus dem Internet erreichbar ist, und Zugriffe nach Möglichkeit auf VPN, Single Sign-On und definierte IP-Adressbereiche beschränken.
- WAF/Reverse-Proxy einsetzen: Einen Web Application Firewall oder Reverse-Proxy mit Regeln gegen verdächtige Requests an den SolrSearch-Endpoint und typische Groovy-Injektion-Muster vorschalten.
- Log-Analyse: Protokolle auf auffällige HTTP-GET-Anfragen an Such-Endpunkte, Groovy-Fehlermeldungen sowie unerklärliche Peaks in der CPU-Auslastung untersuchen.
- Netzwerk-Monitoring: Ausgehenden Traffic auf ungewöhnliche Verbindungen zu unbekannten Hosts analysieren, wie sie für C2-Kommunikation und Kryptominer typisch sind.
Ergänzend empfiehlt sich eine systematische Inventarisierung aller internet-exponierten Dienste, die kontinuierliche Beobachtung des CISA KEV-Katalogs sowie regelmässige interne Scans mit Werkzeugen wie Nuclei im Rahmen von Blue-Team-Tests. Ebenso wichtig sind regelmässige, getestete Backups der XWiki-Daten, um im Ernstfall schnell und kontrolliert wieder
