Critical XWiki vulnerability exploited in crypto mining malware campaigns

A critical security vulnerability in the XWiki collaboration platform is being actively exploited by threat actors to deploy cryptocurrency mining malware on vulnerable systems. 

XWiki Platform is a widely adopted wiki platform that provides runtime services for collaborative applications. The software is used in enterprises, universities, research institutions, and open-source communities globally. The platform enables knowledge management, document collaboration, and workflow automation.

The flaw is tracked as CVE-2025-24893 (CVSS score 9.8), an improper neutralization of input in a dynamic evaluation call (also known as eval injection) in the SolrSearchMacros component of XWiki Platform. The security flaw is caused by insufficient input sanitization in the SolrSearch macro, which is used for querying the internal search index. When attackers craft malicious requests to the /bin/get/Main/SolrSearch endpoint, the 'text' parameter's value is rendered as part of the RSS feed's title and description without proper sanitization of scripting language special characters. This allows script instructions to be interpreted and executed by the XWiki template renderer, enabling arbitrary code execution on vulnerable servers. 

Affected versions of XWiki Platform:

• XWiki Platform versions from 5.3-milestone-2 up to but not including 15.10.11
• XWiki Platform versions from 16.0.0-rc-1 up to but not including 16.4.1

Patched versions:

• XWiki Platform version 15.10.11 and later versions in the 15.x series
• XWiki Platform version 16.4.1 and later versions in the 16.4.x series
• XWiki Platform version 16.5.0RC1 and all subsequent releases

Organizations can verify their current XWiki version by checking the platform's administration interface or reviewing deployment documentation. The patches implement proper input validation in the SolrSearch macro to prevent malicious code execution by correctly sanitizing user input before it is processed by the template renderer.

Cybersecurity researchers at VulnCheck have captured evidence of active exploitation through their canary network infrastructure, which monitors real-world attack attempts against vulnerable systems. The observed attacks originate from Vietnam-based threat actors operating from IP address 123.25.249.88, which has been extensively reported on AbuseIPDB for malicious activity including brute-force attempts as recently as October 2025. 

Attackers inject URL-encoded commands that execute a wget operation, downloading a malicious bash script from a command-and-control server located at IP address 193.32.208.24. This infrastructure hosts malicious payloads through a transfer.sh instance running on port 8080. The initial downloader, designated as x640, is saved to the /tmp directory on compromised systems and functions as a minimal bash wrapper.

After approximately 20 minutes following the initial compromise, attackers return with a second request that executes the previously staged downloader. This delay allows attackers to avoid automated security detection systems that may flag rapid sequential exploitation attempts. The first-stage downloader pulls two follow-on scripts (x521 and x522) from the attacker's infrastructure.

The x521 script fetches and installs a UPX-packed binary named "tcrond", a Monero cryptocurrency miner. The x522 script prepares the system environment by terminating any competing cryptocurrency mining processes that may already be running on the system, ensuring exclusive access to computational resources. The script then launches the malicious mining software configured with connection parameters pointing to c3pool.org mining pools, which aggregate mining efforts and distribute cryptocurrency rewards to participants.

Organizations running XWiki should immediately prioritize upgrading to patched versions. For organizations that cannot immediately upgrade their systems, a temporary workaround is to manually edit the Main.SolrSearchMacros.xml, line 955 of the SolrSearchMacros.xml file in the xwiki-platform-search-solr-ui component should be modified to match the rawResponse macro implementation with a content type of application/xml instead of directly outputting feed content. However, this workaround should be considered a temporary mitigation only, and organizations should plan for full patching as quickly as possible.