CVE-2025-24893: XWiki Platform RCE Vulnerability

CVE-2025-24893 Overview

CVE-2025-24893 is a critical Remote Code Execution (RCE) vulnerability in XWiki Platform, a generic wiki platform offering runtime services for applications built on top of it. This vulnerability allows any unauthenticated guest user to perform arbitrary remote code execution through a crafted request to the SolrSearch endpoint. The flaw enables attackers to inject and execute Groovy code via the search text parameter, completely compromising the confidentiality, integrity, and availability of the entire XWiki installation.

Critical Impact

Unauthenticated attackers can achieve full system compromise through arbitrary code execution, affecting all data and services hosted on the XWiki platform. This vulnerability is actively exploited in the wild and is listed in CISA's Known Exploited Vulnerabilities catalog.

Affected Products

• XWiki Platform versions 5.3 through 15.10.10
• XWiki Platform versions 16.0.0 through 16.4.0
• XWiki Platform version 16.5.0 (prior to RC1)

Discovery Timeline

• February 20, 2025 - CVE-2025-24893 published to NVD
• October 31, 2025 - Last updated in NVD database

Technical Details for CVE-2025-24893

Vulnerability Analysis

This vulnerability exists in the Main.SolrSearchMacros component of XWiki Platform, specifically in the RSS feed generation functionality. The SolrSearch endpoint accepts user-controlled input through the text parameter without proper sanitization before rendering. When a user requests an RSS feed (media=rss), the search text is processed through XWiki's rendering engine, which allows execution of wiki syntax macros including the {{groovy}} macro.

The attack requires no authentication and can be triggered with a simple HTTP GET request. An attacker can inject XWiki wiki syntax containing async and Groovy macros, which are then executed server-side with the privileges of the XWiki application. This represents a classic Code Injection vulnerability where user input is directly interpreted as executable code.

Root Cause

The root cause lies in improper input validation and the unsafe handling of user-supplied content in the SolrSearchMacros.xml file at line 955. The RSS feed output mechanism fails to properly escape or sanitize the search text parameter before processing it through the wiki rendering pipeline. This allows wiki macro syntax (specifically {{async}} and {{groovy}} macros) embedded in the search query to be interpreted and executed rather than treated as literal text.

The vulnerable code path directly outputs content without setting appropriate content type restrictions, allowing arbitrary Velocity and Groovy code execution. The fix introduces a rawResponse macro that properly handles HTTP responses with a content type of application/xml, preventing macro interpretation.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker simply sends a crafted HTTP GET request to the SolrSearch endpoint with URL-encoded Groovy code embedded in the text parameter. The payload uses nested wiki macros: the {{async}} macro ensures synchronous execution, and the {{groovy}} macro contains the arbitrary code to execute.

The exploitation URL pattern follows this structure:

/xwiki/bin/get/Main/SolrSearch?media=rss&text=}}}{{async async=false}}{{groovy}}[PAYLOAD]{{/groovy}}{{/async}}

The following patch from the XWiki security update shows how the vulnerable direct response handling was replaced with a secure rawResponse macro:

   #set ($text = "$!request.text")
   #set ($stripHTMLEnvelope = $request.stripHTMLEnvelope == 'true')
   #set ($output = "#ckeditor_convert($text $toHTML $fromHTML $stripHTMLEnvelope)")
-  #set ($characterEncoding = 'utf-8')
-  ## Make sure the Character Encoding response header matches the character encoding used to write the response and
-  ## compute its length. See CKEDITOR-162: Cannot convert to source code
-  #set ($discard = $response.setCharacterEncoding($characterEncoding))
-  ## We write the output directly to the response to avoid the execution of the Rendering Transformations. Another
-  ## option would be to specify which Rendering Transformations to execute in the query string (XWIKI-13167).
-  ## See CKEDITOR-51: Icon transformations are saved by CKEditor
-  #set ($discard = $response.writer.print($output))
-  ## The content length is measured in bytes and one character can use more than one byte.
-  #set ($discard = $response.setContentLength($output.getBytes($characterEncoding).size()))
-  ## Make sure the entire content is send back to the client.
-  #set ($discard = $response.flushBuffer())
-  ## Make sure XWiki doesn't write any more content to the response.
-  #set ($discard = $xcontext.setFinished(true))
+  #rawResponse($output)
 #else
   The service used by the CKEditor source plugin to convert between HTML and wiki syntax.
 #end

Source: GitHub Commit Update

Detection Methods for CVE-2025-24893

Indicators of Compromise

• HTTP requests to /xwiki/bin/get/Main/SolrSearch containing URL-encoded wiki macro syntax such as {{async}}, {{groovy}}, or {{velocity}}
• Web server logs showing requests with media=rss parameter combined with suspicious text parameters containing encoded curly braces (%7B%7B)
• Unexpected process spawning or network connections originating from the XWiki application server
• Unauthorized modifications to wiki pages or system configurations
• Evidence of data exfiltration or reverse shell connections from the XWiki host

Detection Strategies

• Implement web application firewall (WAF) rules to detect and block requests containing wiki macro patterns ({{groovy}}, {{async}}, {{velocity}}) in URL parameters
• Monitor HTTP access logs for suspicious SolrSearch requests, particularly those with media=rss and encoded special characters in the text parameter
• Deploy network intrusion detection signatures to identify exploitation attempts targeting the SolrSearch endpoint
• Enable verbose logging on XWiki application to capture and alert on Groovy script execution events

Monitoring Recommendations

• Establish baseline network behavior for XWiki servers and alert on anomalous outbound connections
• Monitor for unauthorized file system changes within the XWiki installation directory
• Implement real-time alerting for any unauthenticated requests to RSS feed endpoints with macro-like syntax
• Review XWiki audit logs regularly for evidence of unauthorized code execution or privilege escalation

How to Mitigate CVE-2025-24893

Immediate Actions Required

• Upgrade XWiki Platform immediately to version 15.10.11, 16.4.1, or 16.5.0RC1 or later
• If immediate upgrade is not possible, apply the manual workaround by editing the SolrSearchMacros.xml file
• Temporarily restrict public access to the XWiki instance if it contains sensitive data
• Review server logs for evidence of prior exploitation attempts
• Scan systems for indicators of compromise before and after remediation

Patch Information

XWiki has released patched versions that address this vulnerability. The fix introduces a generic Velocity macro called rawResponse that properly sets HTTP response content types to prevent macro interpretation. Affected users should upgrade to one of the following versions:

• XWiki 15.10.11 - For users on the 15.x LTS branch
• XWiki 16.4.1 - For users on the 16.4.x branch
• XWiki 16.5.0RC1 - For users following the latest development branch

The security patch is available in the GitHub Commit Update. Additional details can be found in the GitHub Security Advisory GHSA-rr6p-3pfg-562j and JIRA Issue XWIKI-22149.

Workarounds

• Edit Main.SolrSearchMacros in SolrSearchMacros.xml at line 955 to use the rawResponse macro pattern from macros.vm#L2824 with a content type of application/xml
• Implement WAF rules to block requests containing wiki macro syntax in the text parameter of SolrSearch requests
• Restrict access to the /xwiki/bin/get/Main/SolrSearch endpoint to authenticated users only via web server configuration
• Deploy network-level controls to limit inbound access to the XWiki application from untrusted networks

# Apache configuration example to restrict SolrSearch access
<Location "/xwiki/bin/get/Main/SolrSearch">
    Order deny,allow
    Deny from all
    # Allow only from trusted internal networks
    Allow from 10.0.0.0/8
    Allow from 192.168.0.0/16
</Location>