XWiki CVE-2025-24893: Guest RCE via SolrSearch

What to do

1. Find every XWiki instance and record its version from the page footer or the Administration screen.
2. Upgrade anything below 15.10.11 or 16.4.1 to a current supported release.
3. If you cannot upgrade today, apply the advisory's workaround in Main.SolrSearchMacros or block /bin/get/Main/SolrSearch at the reverse proxy.
4. Remove guest access and direct internet exposure where the wiki does not need to be public.
5. If an unpatched instance was reachable after March 2025, run the hunt below and rebuild the host if you find exploitation.

How to check if you are affected or compromised

• Search access logs for requests to Main/SolrSearch with media=rss whose text parameter contains groovy, async, wget, curl or base64.
• Look for unexpected files in /tmp and /var/tmp, a process named tcrond, or connections to c3pool.org.
• Check for outbound traffic to the VulnCheck indicators, such as 193.32.208.24:8080 and 74.194.191.52.
• Review the XWiki host for sustained high CPU, new cron entries and processes started by the servlet container user.

What happened#

XWiki is an open-source Java wiki used for internal documentation and knowledge bases. Its search page had an eval injection flaw. A guest, with no login, could send a request to SolrSearch with media=rss and a crafted text parameter. XWiki then ran the embedded Groovy code on the server. The XWiki advisory says this affects the confidentiality, integrity and availability of the whole installation. It rates the bug CVSS 3.1 9.8, and so does NVD.

The timing is unusual. John Kwak of Trend Micro's Zero Day Initiative reported the bug, and XWIKI-22149 was opened on May 6, 2024 and resolved on June 12, 2024. The fixes shipped in 15.10.11, 16.4.1 and 16.5.0-rc-1. The advisory and CVE record were not published until February 20, 2025. The CVE record includes a harmless test request, which made a working exploit easy to write.

Exploitation followed. VulnCheck says it added the bug to its own exploited list in March 2025, after Cyble, Shadowserver and CrowdSec reported attempts. On October 28, 2025, it described a full two-step chain from 123.25.249.88. A first request used wget to save a downloader named x640 to /tmp/11909. A second request ran it. The scripts installed a UPX-packed miner called tcrond under /var/tmp that mined through c3pool.org. CISA added the CVE to the KEV catalog two days later, on October 30.

On November 14, VulnCheck reported a clear rise in attacks. The RondoDox botnet started on November 3, fetching rondo.<value>.sh scripts. Other miners appeared on November 7, reverse-shell attempts on October 31 and November 11, and mass Nuclei scanning ran cat /etc/passwd. BleepingComputer reported the same findings.

Who is affected#

XWiki Platform from 5.3-milestone-2 up to 15.10.11, and from 16.0.0-rc-1 up to 16.4.1. That spans about ten years of releases. Instances that let anonymous users view pages are the easiest targets, because the advisory says any guest can trigger the bug.

Do you really need to act?#

If you upgraded after mid-2024 and stayed current, no. If any XWiki is still on an older build, yes. The exploit is a single GET request, public tools scan for it, and several groups have used it. Wikis are often forgotten on old versions, and they hold internal documents and credentials pasted into pages. Upgrading does not remove a miner, botnet agent or web shell planted earlier. So check the logs of any instance that was reachable while unpatched.

What to do now#

1. Inventory XWiki instances and read each version from the page footer or the Administration screen.
2. Upgrade anything below 15.10.11 or 16.4.1 to a current release.
3. If an upgrade must wait, apply the advisory's workaround. It edits Main.SolrSearchMacros to use the rawResponse macro with an application/xml content type. You can also block /bin/get/Main/SolrSearch at the proxy.
4. Turn off guest access and put internal wikis behind SSO or a VPN.
5. If you find signs of exploitation, rebuild the host and rotate any secrets stored in the wiki or its configuration.

How to tell if you were hit#

Search proxy and servlet logs. For example, grep -E "SolrSearch.*media=rss" access.log | grep -iE "groovy|async|wget|curl|base64". VulnCheck notes that base64-encoded payloads still show up in the URL. On the host, look for odd files in /tmp and /var/tmp, a tcrond process, high CPU, and new cron jobs. Check egress logs for c3pool.org, 193.32.208.24 on port 8080, and the RondoDox payload server 74.194.191.52.

Timeline#

• May 6, 2024 — ZDI's report is filed as XWIKI-22149.
• Jun 12, 2024 — The issue is resolved for 15.10.11, 16.4.1 and 16.5.0-rc-1.
• Feb 20, 2025 — XWiki publishes the advisory and the CVE.
• Oct 28, 2025 — VulnCheck documents a miner deployment chain.
• Oct 30, 2025 — CISA adds the CVE to KEV.
• Nov 3, 2025 — RondoDox starts exploiting the bug.
• Nov 14, 2025 — VulnCheck reports multiple independent attackers.

Vulnerability records

• CVE-2025-24893 · KEV 2025-10-30 · XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. XWiki — GHSA-rr6p-3pfg-562j: Remote code execution as guest via SolrSearchMacros request github.com
2. XWiki Jira — XWIKI-22149 jira.xwiki.org
3. CVE record — CVE-2025-24893 cve.org
4. NVD — CVE-2025-24893 nvd.nist.gov
5. CISA — Known Exploited Vulnerabilities: CVE-2025-24893 cisa.gov
6. VulnCheck — XWiki CVE-2025-24893 exploited in the wild vulncheck.com
7. VulnCheck — XWiki Under Increased Attack vulncheck.com

Coverage and analysis

1. BleepingComputer — RondoDox botnet malware now hacks servers using XWiki flaw bleepingcomputer.com