CVE-2025-24893: XWiki Platform Eval Injection Vulnerability

CVE-2025-24893 is an eval injection vulnerability in the XWiki Platform that can let any guest user achieve arbitrary remote code execution by sending a crafted request to the SolrSearch component. Because unauthenticated guests can trigger it, successful abuse can give an attacker full control of the underlying host or application process, putting wiki content, credentials, and connected systems at risk. Confirm exact impact and fixed releases against the vendor advisory.

How it works

The flaw belongs to CWE-95 (Improper Neutralization of Directives in Dynamically Evaluated Code, often called eval injection). In this class of weakness, user-controlled input reaches a language construct that evaluates or executes code without sufficient sanitization or sandboxing. According to the CISA summary, an attacker who can reach the SolrSearch endpoint can supply input that the platform evaluates, resulting in arbitrary remote code execution. No authentication is required; any guest can attempt the request. Exact request parameters, payload format, and execution context are not detailed here and must be verified in the vendor advisory; defenders should treat any unauthenticated access to SolrSearch as potentially dangerous until patched.

Am I affected? How to find it in your systems

XWiki Platform is commonly deployed as a collaborative wiki or knowledge-base application, often on Linux or Windows servers, inside containers, or as a cloud-hosted instance. Inventory steps:

• Search configuration management databases, package inventories, and container registries for “XWiki” or the XWiki Platform package name.
• Examine web-server or reverse-proxy logs for paths containing SolrSearch or related search endpoints.
• Check running processes and listening ports associated with the XWiki application server (typically a Java servlet container).
• Review version strings reported by the XWiki administration interface or installation files; compare them with the fixed versions listed in the vendor advisory.

Telemetry that may indicate exploitation attempts includes unusual or malformed requests to SolrSearch, unexpected process creation or shell activity spawned by the XWiki Java process, and anomalous outbound connections originating from the wiki host. Because public detail on exact indicators is limited, treat any guest-accessible SolrSearch traffic as suspicious until the instance is confirmed patched.

How to remediate

Apply the vendor-supplied update for XWiki Platform as soon as it is available; this is the primary remediation. Follow the installation and verification steps published in the official advisory. After patching:

• Restart the application and confirm the new version is reported by the administration console.
• Re-test that guest access to SolrSearch no longer permits code evaluation (using only non-destructive checks recommended by the vendor).
• Harden the remaining surface: restrict the search feature to authenticated users if business needs allow, enforce least-privilege for the XWiki process account, and ensure the host OS and Java runtime are current.

CISA also advises applying mitigations per vendor instructions, following applicable BOD 22-01 guidance for cloud services, or discontinuing use of the product if mitigations are unavailable.

If you can't patch immediately

Until the vendor update can be installed, reduce exposure with compensating controls:

• Network segmentation: place XWiki behind a firewall or reverse proxy that permits access only from trusted networks or authenticated users; block anonymous internet access to SolrSearch paths.
• Virtual patching / WAF: deploy a web-application firewall rule that inspects and blocks requests containing suspicious evaluation patterns directed at SolrSearch (tune carefully to avoid false positives).
• Feature disablement: if the Solr-based search functionality is not required, disable or remove the SolrSearch component according to vendor documentation.
• Monitoring: enable detailed request logging for the search endpoint, alert on any guest traffic to it, and watch for process-creation events from the XWiki service account.
• Credential and secret hygiene: rotate any secrets stored in the wiki and limit the privileges of the service account that runs XWiki.

These measures lower risk but do not eliminate the vulnerability; schedule the official patch promptly.

If your data may have been exposed

Vulnerabilities that allow unauthenticated remote code execution can lead to full system compromise and subsequent data theft or ransomware deployment (ransomware use of this specific CVE is not documented). If you suspect exploitation, isolate the host, preserve logs and memory images, and begin incident-response procedures. As a quick personal check, you can run a free exposure scan of your email address against known breach data sets to see whether associated credentials have appeared in public dumps.