Exploited: XWiki Remote Code Execution Vulnerability (CVE-2025-24893)

Overview

A newly discovered critical vulnerability in the XWiki Platform, tracked as CVE-2025-24893, allows unauthenticated remote code execution (RCE) through the SolrSearch macro. This vulnerability was assigned a CVSS score of 9.8 as rated by GitHub, Inc.)

, can be exploited by attackers to execute arbitrary Groovy code on affected servers, potentially leading to data breaches, privilege escalation, and full system compromise.

Given the severity of this issue, organizations using The vulnerability affects XWiki Platform versions from 5.3-milestone-2 up to but not including 15.10.11, and from 16.0.0-rc-1 up to but not including 16.4.1.

must take immediate action to mitigate the risk.

The Vulnerability Explained

CVE-2025-24893 stems from insufficient input sanitization in the SolrSearch macro. This macro, used for querying the internal search index, does not properly validate user input, allowing attackers to inject and execute arbitrary Groovy code via specially crafted requests.

An attacker can exploit this flaw by sending an unauthenticated HTTP request with a malicious payload to the vulnerable XWiki instance. The server then executes the injected code, granting the attacker full control over the system.

Technical Breakdown

The vulnerable endpoint:

http://<host>/xwiki/bin/get/Main/SolrSearch?media=rss&text=<payload>

By injecting malicious Groovy code, an attacker can gain unauthorized access. Here’s an example of a proof-of-concept (PoC) exploit:

http://<host>/xwiki/bin/get/Main/SolrSearch?media=rss&text=}}}{{async async=false}}{{groovy}}println("Exploit Successful! Result: " + (23 + 19)){{/groovy}}{{/async}}

If the system is vulnerable, it will return:

Exploit Successful! Result: 42

This confirms that remote code execution (RCE) is possible. Attackers can replace the Groovy payload with more malicious commands, such as fetching malware, establishing backdoors, or exfiltrating sensitive data.

How Attackers Are Exploiting CVE-2025-24893

Exploitation in the Wild

While there is no confirmed active exploitation of this vulnerability yet, security researchers warn that attackers could use it to:

• Deploy webshells for persistent access
• Install cryptominers to leverage server resources
• Create backdoors for long-term control
• Exfiltrate sensitive data stored in XWiki

Who is at Risk?

Any organization using affected versions of XWiki (5.3-milestone-2 through 15.10.10 and 16.0.0-rc-1 through 16.4.0) is vulnerable. Given that XWiki is widely adopted by enterprises, universities, and open-source communities, this vulnerability presents a significant security risk.

Mitigation: How to Protect Your XWiki Instance

1. Immediate Fix – Upgrade to Patched Versions

The official patched versions that resolve this vulnerability are:

• XWiki 15.10.11
• XWiki 16.4.1
• XWiki 16.5.0RC1

Organizations should immediately upgrade to these versions to mitigate the risk. The patches address the improper input validation in the SolrSearch macro, preventing malicious code execution.

2. Temporary Workaround (If You Cannot Upgrade Immediately)

For organizations unable to upgrade immediately, a temporary fix can be applied by modifying the SolrSearchMacros.xml configuration:

Workaround: Restrict Output Format

Modify SolrSearchMacros.xml to ensure the response type is strictly XML:

<macro name="rawResponse">

   <code>

      <![CDATA[

         response.setContentType("application/xml")

      ]]>

   </code>

</macro>

This helps prevent the execution of injected scripts by restricting improper rendering of user-supplied content.

Firewall Rule Recommendation

To further protect your XWiki instance, configure WAF (Web Application Firewall) rules to block exploit attempts targeting the SolrSearch endpoint. If using ModSecurity, add the following rule:

SecRule REQUEST_URI “@contains /xwiki/bin/get/Main/SolrSearch” I am running a few minutes late; my previous meeting is running over.

“id:100001,deny,status:403,msg:’Blocking XWiki RCE Exploit'”

This will block unauthorized requests to the vulnerable endpoint.

Indicators of Compromise (IoCs)

Organizations should audit their XWiki logs for unusual access patterns and check for potential compromise indicators, such as:

• Unexpected requests to SolrSearch with suspicious payloads
• Newly created admin accounts or modified user privileges
• Unusual outbound traffic (suggesting data exfiltration or malware downloads)
• Unauthorized files in /xwiki/bin/get/ or /xwiki/data/ directories

To search for suspicious requests in Apache/Nginx logs, use:

grep “SolrSearch” /var/log/apache2/access.log

grep “SolrSearch” /var/log/nginx/access.log

If any anomalies are detected, assume compromise and perform an immediate security assessment.

Final Thoughts

CVE-2025-24893 is a highly critical vulnerability that enables unauthenticated remote code execution (RCE) in XWiki instances. While there is no public evidence of active exploitation yet, the availability of PoC exploits makes it crucial for organizations to prioritize upgrading to patched versions.

For those unable to upgrade immediately, implementing temporary mitigations such as modifying the SolrSearchMacros.xml and deploying WAF rules can help reduce the risk.

Security teams should actively monitor logs, review system integrity, and apply necessary hardening measures to protect their environments from potential exploitation.

Am I Impacted by CVE-2025-24893?

IONIX is actively tracking this vulnerability. Our security research team has developed a full exploit simulation model based on known exploits. This allows us to assess which customers have impacted assets. IONIX customers can view updated information on their specific assets in the threat center of the IONIX portal.

IONIX customers will see updated information on their specific assets in the threat center of the IONIX portal.

References

• CVE-2025-24893 – NVD
• XWiki Security Advisory
• XWiki Patch Commit
• Vulners Database – CVE-2025-24893
• XWiki Official Documentation

---

This version now follows the exact structure of the reference blog while ensuring a technical, security-focused, and actionable approach. Let me know if you need any refinements! 🚀