Yes. CISA added CVE-2025-24893 to its Known Exploited Vulnerabilities catalogue on 30 October 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. XWiki Platform contains an eval injection vulnerability that could allow any guest to perform arbitrary remote code execution through a request to SolrSearch.
How to interpret exploitation status for CVE-2025-24893
For an actively exploited CVE, the operational question is not whether a proof-of-concept exists, but whether you should treat the flaw as a live exposure. CISA’s KEV inclusion is the clearest public signal that defenders should assume exploitation is already happening and prioritise response on that basis, not on abstract severity alone. The relevant starting points are the CISA Known Exploited Vulnerabilities Catalog and the CVE Program.
That framing matters because CVE records identify the flaw, but KEV tells you whether the vulnerability has crossed from theoretical risk into active defender priority. For xwiki platform eval injection, the practical implication is that exposure assessment should begin immediately, even if you have not yet seen obvious signs of abuse in your environment.
When a vulnerability is in KEV, the first task is to determine whether any internet-facing or internally reachable XWiki instance is present, then confirm whether the specific application path and version are exposed to request handling that could reach the vulnerable SolrSearch flow. If you operate the platform for shared collaboration or knowledge work, assume the blast radius is broader than a single server because the application often contains sensitive internal content and authentication context.
What the exploitation path means for defenders
The underlying issue is an eval injection condition that can allow arbitrary remote code execution through a request to SolrSearch. That is a high-impact application flaw because it turns a normal request path into code execution, which can be used for webshell placement, data theft, credential harvesting, or lateral movement if the host has trust relationships with other systems. The NIST National Vulnerability Database is useful for confirming the record details, but the remediation decision should be driven by exposure, not by score alone.
In practice, exploitation often starts with a single request that reaches the vulnerable endpoint, then moves quickly to post-exploitation activity on the host. Because the payload is code execution rather than a narrow data leak, the attacker’s next step may be to implant persistence, inspect application secrets, or pivot to adjacent internal services. That makes this class of issue more than a patching problem, it is also a compromise-assessment problem.
Defenders should also treat the application boundary as a trust boundary. If XWiki has access to internal file shares, directory services, email systems, or service credentials, a successful exploit can expose those downstream dependencies even if the initial attack begins at the web layer.
What to do if patching or mitigation is delayed
If you cannot remediate immediately, concentrate on reducing reachability and shortening attacker dwell time. Limit access to the application, place it behind strong authentication where possible, and monitor for abnormal requests to the affected search path, unexpected child processes, web shells, or outbound connections from the host. The most useful control is the one that prevents the vulnerable code path from being reachable long enough for an attacker to exploit it.
- Confirm whether any XWiki instance is exposed to untrusted users or the internet.
- Check server logs and process activity for suspicious SolrSearch requests, command execution, or new files in web-accessible locations.
- Review neighbouring systems for reuse of service credentials, API keys, or secrets stored on the host.
- Restrict outbound connectivity from the application server where business operations allow it.
If there is evidence of successful exploitation, rotate credentials and invalidate sessions or tokens that the system could have accessed, especially if the platform integrates with single sign-on, internal directories, or automation accounts. In many real incidents, the first compromised host is only the entry point, not the end state.
Risk and Threat Considerations
An actively exploited remote code execution flaw creates immediate exposure because the attacker does not need valid user access to begin abuse. The risk is not limited to the XWiki application itself: once code execution is obtained, the host becomes a launch point for persistence, credential access, and lateral movement into connected systems.
Failure mechanism: The vulnerable request handling path accepts attacker-controlled input and reaches an eval-style execution context, which lets a crafted request execute code on the server.
Impact: A successful exploit can lead to full application compromise, data exposure, modification of internal content, theft of secrets, and follow-on compromise of adjacent systems that trust the host.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Active exploitation requires rapid exposure discovery and remediation prioritisation. |
| Recommendation — Prioritise the vulnerable XWiki host for rapid scanning, validation and remediation. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | This CVE demands urgent remediation and controlled exception handling. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Exploitation checks depend on reviewing logs for suspicious request and execution activity. | |
| IA-5 — Authenticator Management | RCE can expose credentials, tokens and sessions that should be rotated after compromise. | |
| Recommendation — Accelerate remediation for the affected system and document any temporary exception. Review logs for suspicious SolrSearch requests, process creation and outbound activity. Rotate exposed credentials, tokens and sessions if compromise evidence is found. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Detection and forensic validation depend on sufficient logging around the exploit path. |
| Recommendation — Ensure application logs capture suspicious search requests and error conditions for investigation. | ||
Practitioner Guidance
What to prioritise: Treat KEV-listed exploitation as a live incident response trigger, not a normal backlog item. If the platform is reachable, patching and exposure reduction should take precedence over routine maintenance work.
What to verify: Validate whether the host has any indication of post-exploitation activity, especially new processes, suspicious outbound traffic, web-root changes, or access from unexpected accounts after the vulnerable request path was hit.
Decision rule: If you cannot patch immediately, compensate by narrowing reachability, increasing logging, and assuming possible compromise until you can prove otherwise.
Practitioner takeaway: For a KEV-listed RCE, the right assumption is active abuse until you have evidence to the contrary, and the response should cover both the vulnerable application and anything it could already have exposed.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- CVE-2025-24893 (XWiki Platform Eval Injection)
- Is CVE-2025-4428 (Ivanti Endpoint Manager Mobile (EPMM) Code Injection) being exploited in the wild?
- Is CVE-2025-66644 (Array Networks ArrayOS AG OS Command Injection) being exploited in the wild?
- Is CVE-2025-59689 (Libraesva Email Security Gateway Command Injection) being exploited in the wild?