Remote code execution as guest via SolrSearchMacros request in xwiki
Affects xwiki-platform and its Solr search UI from 5.3-milestone-2 to 15.10.11, and from 16.0.0-rc-1 to 16.4.1, in default installations. Fixed in 15.10.11 and 16.4.1.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Actively exploited
- Fix
- Fixed in 15.10.11, 16.4.1
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
A guest user can run arbitrary code on servers running XWiki Platform, a generic wiki platform, through a crafted request to its Solr search feature. This lets an attacker compromise the confidentiality, integrity, and availability of the entire XWiki installation.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any guest can perform arbitrary remote code execution through a request to `SolrSearch`. This impacts the confidentiality, integrity and availability of the whole XWiki installation. To reproduce on an instance, without being logged in, go to `<host>/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28"Hello%20from"%20%2B%20"%20search%20text%3A"%20%2B%20%2823%20%2B%2019%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D%20`. If there is an output, and the title of the RSS feed contains `Hello from search text:42`, then the instance is vulnerable. This vulnerability has been patched in XWiki 15.10.11, 16.4.1 and 16.5.0RC1. Users are advised to upgrade. Users unable to upgrade may edit `Main.SolrSearchMacros` in `SolrSearchMacros.xml` on line 955 to match the `rawResponse` macro in `macros.vm#L2824` with a content type of `application/xml`, instead of simply outputting the content of the feed.
Timeline
- CVE published
- Added to CISA KEV
CISA has evidence of exploitation in the wild
- CISA remediation deadline
Due date for US federal agencies to patch
- Record last updated
- EPSS reached 10%
FIRST estimates at least a 10% chance of exploitation in the next 30 days
Affected versions
- xwiki xwiki-platform
From 5.3-milestone-2 · fixed in 15.10.11; From 16.0.0-rc-1 · fixed in 16.4.1
- org.xwiki.platform:xwiki-platform-search-solr-uiMaven
From 5.3-milestone-2 · fixed in 15.10.11
- org.xwiki.platform:xwiki-platform-search-solr-uiMaven
From 16.0.0-rc-1 · fixed in 16.4.1
References 5
GitHub · xwiki/xwiki-platform
- Advisory GHSA-rr6p-3pfg-562j
- Commit 67021db9
- xwiki-platform-core/xwiki-platform-search/xwiki-platform-search-solr/xwiki-platform-search-solr-ui/src/main/resources/Main/SolrSearchMacros.xml · L955
- xwiki-platform-core/xwiki-platform-web/xwiki-platform-web-templates/src/main/resources/templates/macros.vm · L2824
jira.xwiki.org
Questions about CVE-2025-24893
What does this mean?
A guest user who is not logged in can send a SolrSearch request with media=rss that makes the XWiki server run code. The impact covers the whole XWiki installation.Source: jira.xwiki.org, github.com
Am I affected, and how do I check?
Versions from 5.3-milestone-2 up to 15.10.11 and from 16.0.0-rc-1 up to 16.4.1 of xwiki-platform and the xwiki-platform-search-solr-ui module are in scope. The issue applies to default installations where the Main.Search template calls the Solr Search UI extension.Source: jira.xwiki.org, github.com
What should I do about it?
Upgrade to XWiki 15.10.11 or 16.4.1, which include the fix. The patch is also in 16.5.0RC1.Source: jira.xwiki.org, github.com
Is it being exploited?
Yes. CISA added it to its Known Exploited Vulnerabilities catalog on 2025-10-30, which means it has evidence of attacks. No public exploit code is tracked.Source: cisa.gov, cve.now feed data