Home » RondoDox Botnet Exploits XWiki CVE-2025-24893 on Servers

RondoDox Botnet Exploits XWiki CVE-2025-24893 on Servers

Compromised XWiki server targeted by RondoDox using CVE-2025-24893 eval injection flaw Concept image showing how the RondoDox botnet exploits CVE-2025-24893 to compromise unpatched XWiki servers

Most security teams know RondoDox as a relatively new botnet that loves edge devices, routers, DVRs and anything cheap, exposed and unpatched. Meanwhile, many teams treat their internal wiki as background noise. However, XWiki now sits in the crosshairs of the same campaign.

RondoDox operators added CVE-2025-24893, a critical eval injection flaw in XWiki, to their exploit arsenal. As a result, any internet-facing XWiki instance that still runs vulnerable versions can become one more node in a mining-focused botnet, and sometimes one more foothold inside a larger environment.

Therefore, security teams need to treat the wiki like any other internet-facing application, not as a harmless documentation engine.

𝗖𝗩𝗘-𝟮𝟬𝟮𝟱-𝟮𝟰𝟴𝟵𝟯: 𝗣𝗿𝗲-𝗔𝘂𝘁𝗵 𝗘𝘃𝗮𝗹 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗼𝗻 𝗦𝗼𝗹𝗿𝗦𝗲𝗮𝗿𝗰𝗵

CVE-2025-24893 hits the XWiki Platform’s SolrSearch functionality. In affected versions, the application mishandles search parameters and evaluates attacker-controlled Groovy expressions in the context of the server. Because XWiki exposes SolrSearch to guest users, the flaw grants unauthenticated remote code execution to anyone who can reach the endpoint.

In practice, an attacker sends a crafted request against the SolrSearch macro (for example via a path such as /bin/get/Main/SolrSearch on vulnerable builds). The injected payload executes directly on the server, which means the adversary gains shell-level control with a single HTTP request.

XWiki maintainers fixed the issue in releases like 15.10.11, 16.4.1 and 16.5.0 RC1. However, many deployments lag behind because teams either forget the wiki or assume that limited external usage lowers risk. RondoDox now exploits that gap.

𝗥𝗼𝗻𝗱𝗼𝗗𝗼𝘅 𝗕𝗼𝘁𝗻𝗲𝘁 𝗣𝗿𝗼𝗳𝗶𝗹𝗲: 𝗙𝗿𝗼𝗺 𝗘𝗱𝗴𝗲 𝗗𝗲𝘃𝗶𝗰𝗲𝘀 𝘁𝗼 𝗪𝗶𝗸𝗶 𝗦𝗲𝗿𝘃𝗲𝗿𝘀

Initially, researchers saw RondoDox focus on command-injection bugs in routers, DVRs and small-office network gear. Trend-style telemetry and later work from several vendors showed the botnet chaining more than fifty vulnerabilities across roughly thirty products to gain shell access, deploy multi-architecture binaries and run crypto-mining or DDoS tasks.

As the campaign matured, the operators treated XWiki as simply another internet-exposed service. They already scan large address ranges and maintain exploit modules for many CVEs, so adding SolrSearch eval injection cost them very little. However, the upside looks attractive: wiki servers usually sit on better hardware than CCTV boxes and often reach deeper into internal networks.

In addition, XWiki frequently runs with access to LDAP, SSO and internal data sources. Because of that, compromise of the wiki can set up lateral movement beyond “just” mining.

𝗘𝘅𝗽𝗹𝗼𝗶𝘁 𝗖𝗵𝗮𝗶𝗻: 𝗙𝗿𝗼𝗺 𝗦𝗰𝗮𝗻 𝘁𝗼 𝗠𝗶𝗻𝗲𝗿

RondoDox follows a straightforward exploit chain against XWiki:

First, scanners probe for XWiki fingerprints and version information. They look for characteristic response headers, paths and HTML signatures that distinguish XWiki from other Java web applications.

Next, they fire SolrSearch requests that carry malicious Groovy payloads in search parameters. Because vulnerable versions evaluate those expressions as part of the SolrSearch macro, the botnet gains code execution without any authentication.

Then, the operator pulls a small staging script. That script downloads and runs the main botnet binary plus a crypto-mining payload. VulnCheck canaries and other telemetry sources already show exactly this two-stage pattern: RCE via CVE-2025-24893 followed by coin-miner deployment.

Finally, the compromised server joins the RondoDox C2 infrastructure. It starts mining and remains ready for additional tasks such as scanning, DDoS or further exploitation of neighboring systems. Because the whole sequence rides on one HTTP endpoint, the attack surface looks small yet extremely powerful.

𝗧𝗶𝗺𝗲𝗹𝗶𝗻𝗲: 𝗙𝗿𝗼𝗺 𝗗𝗶𝘀𝗰𝗹𝗼𝘀𝘂𝗿𝗲 𝘁𝗼 𝗞𝗘𝗩 𝗔𝗻𝗱 𝗕𝗼𝘁𝗻𝗲𝘁

XWiki maintainers disclosed and patched the eval injection earlier in 2025. Shortly after that, exploit proof-of-concepts appeared on GitHub, and Metasploit gained a dedicated module. Therefore, the vulnerability quickly moved from internal advisory to widely reproducible exploit.

By mid-year, research platforms and canary networks observed live exploitation of CVE-2025-24893 to drop miners, even before every major government list recognized it. Later, CISA added the XWiki eval injection to the Known Exploited Vulnerabilities catalog and required US federal agencies to remediate within tight deadlines.

However, KEV inclusion did not instantly fix private-sector deployments. Many organizations still treat the wiki as “just documentation,” not as part of critical attack surface. RondoDox profited from that blind spot and kept abusing unpatched servers even after the KEV entry went live.

𝗪𝗵𝘆 𝗫𝗪𝗶𝗸𝗶 𝗠𝗮𝗸𝗲𝘀 𝗮 𝗚𝗼𝗼𝗱 𝗕𝗼𝘁𝗻𝗲𝘁 𝗧𝗮𝗿𝗴𝗲𝘁

XWiki often runs on well-provisioned application servers because teams expect it to handle internal traffic and search workloads. Consequently, a single compromise yields far more CPU power for mining than a random IoT camera.

Moreover, many deployments integrate XWiki with corporate identity providers, legacy content sources and automation glue. Attackers know that admin accounts sometimes

3 thoughts on “RondoDox Botnet Exploits XWiki CVE-2025-24893 on Servers

Leave a Reply

Your email address will not be published. Required fields are marked *