Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| org.xwiki.platform:xwiki-platform-search-solr-ui | maven | >= 5.3-milestone-2, < 15.10.11 | 15.10.11 |
| org.xwiki.platform:xwiki-platform-search-solr-ui | maven | >= 16.0.0-rc-1, < 16.4.1 | 16.4.1 |
Miggo AIRoot Cause AnalysisThe vulnerability allows remote code execution via a crafted 'text' parameter in a request to Main/SolrSearch when media=rss. The core issue lies in how the RSS feed content, which includes this user input, is rendered.
The commit 67021db9b8ed26c2236a653269302a86bf01ef40 patches this by modifying Main/SolrSearchMacros.xml.
outputRSSFeed macro within Main.SolrSearchMacros.xml was directly outputting the feed content using $xwiki.feed.getFeedOutput($feed, 'rss_2.0'). This direct output allowed the XWiki rendering engine to process any embedded scripts (like Groovy macros) within the feed content that originated from the user's 'text' parameter. This is where the vulnerability (unsafe rendering sink) was located. The patch changes this to use a new #rawResponse macro, which explicitly sets the content type and writes the data raw, crucially calling $xcontext.setFinished(true) to prevent further rendering and script execution.handleSolrSearchRequest macro, also in Main.SolrSearchMacros.xml, is responsible for handling the incoming request. It takes the request.text (user input) and uses it to create the feed via $services.search.solr.createFeed(...). This feed is then passed to outputRSSFeed. Therefore, handleSolrSearchRequest is the function that processes the potentially malicious input and directs it to the vulnerable rendering logic in outputRSSFeed.Both macros are identified: outputRSSFeed for containing the vulnerable rendering code and handleSolrSearchRequest for processing the malicious input and calling the vulnerable rendering part. The names provided are the Velocity macro names, which are the most precise identifiers in this context.