How to Audit Your XWiki Platform Against Actively Exploited RCE Vulnerabilities

TL;DR — What You Must Do Now

1. Identify versions of all XWiki instances; anything <15.10.11 or <16.4.1 is vulnerable to CVE-2025-24893. 
2. Hunt for exploitation (past 30–90 days): SolrSearch macro abuse, suspicious Groovy evaluations, sudden Java/Tomcat child processes, coin-miner drops. 
3. Patch/upgrade immediately and apply gateway/endpoint mitigations from the checklists below. 

1) What’s being exploited right now?

CVE-2025-24893 (SolrSearch macro SSTI → unauthenticated RCE) is under active exploitation in the wild; multiple reports show live two-stage chains delivering coin-miners and other payloads. The flaw affects a wide range of releases prior to 15.10.11 and 16.4.1. 

Exploit modules and public PoCs exist (risk of broad replication). Treat this as a high-likelihood incident if you are unpatched.

There are also older XWiki RCE classes (e.g., 2024/2023 issues) that your audit should quickly sanity-check if you’re several versions behind.

2) Inventory & Version Audit (10-minute pass)

1. List every XWiki URL (dev, test, prod, internal). Confirm the running version from the footer or /xwiki/bin/Admin/XWikiPreferences (if accessible) and server package metadata.
2. Flag vulnerable builds: anything <15.10.11 (LTS train) or <16.4.1 (stable train). Plan upgrade to ≥15.10.11 or ≥16.4.1 (or 16.5.0-RC1 if advised).
3. Note guest access (registration enabled? public pages with macros?). Guest/unauth paths increase risk/severity. 

3) Detection & Hunts (App/Host/Network)

Application (XWiki/Tomcat logs)

• Search access logs for repeated hits to SolrSearch or Main.SolrSearchMacros with unusual query params, template fragments, or Groovy-like payload fragments. :contentReference[oaicite:9]{index=9}
• Look for stack traces or WARN lines referencing template evaluation / macro rendering failures around those requests.

Host/EDR (Linux)

• Correlate java/catalina processes spawning shells, curl/wget, sh/bash, or miners soon after suspicious web hits. Coin-mining post-exploitation was observed in the wild. 
• Monitor new files under Tomcat/XWiki webapp temp dirs or /tmp shortly after SolrSearch requests.

Network/NDR

• Flag sudden outbound to newly registered hosts or paste/code hosting soon after SolrSearch requests. (Exploit kits often fetch payloads from throwaway infra.) 

WAF/IDS Concepts (tune before prod)

# Suricata (concept) — suspicious SolrSearch macro probes
alert http any any -> $HOME_NET any (
  msg:"XWiki SolrSearch macro probe (CVE-2025-24893 class)";
  http.uri; content:"/SolrSearch"; nocase;
  pcre:"/q=.*(\$|%24|\\{\\{|\")/Ui";  # crude SSTI-ish hint — tune
  classtype:web-application-attack; sid:925893; rev:1;
)

Use as detections and triage signals, not blanket blocks, until tuned.

4) Emergency Mitigations (before patch)

1. Patch now to ≥15.10.11 or ≥16.4.1 (or 16.5.0-RC1). If patching is delayed, disable or restrict SolrSearch macro exposure and block risky query params at WAF. 
2. Lock down guest access and public registration; several XWiki RCE issues increase impact when guests are enabled.
3. Egress controls: deny outbound from the XWiki host except to allowlisted repos; this blunts post-exploitation payload fetch/mining
4. Snapshot & monitor: take a VM snapshot / filesystem backup; enable verbose app logs for SolrSearch handling during the observation window.

5) Hardening & Ongoing Governance

• Keep to secure trains and follow vendor/security advisories for SolrSearch macro fixes and future rendering-engine RCEs. 
• Reduce macro attack surface: limit powerful macros for guest/anonymous contexts; review rendering/“script” macro policies after recent fixes. 
• Threat model uploads/search: validate user-controlled inputs; log/alert on template errors and Groovy evaluation traces.
• IR runbooks: if compromise is suspected, rotate secrets used by XWiki (DB creds, SMTP, OAuth), rebuild from clean media, and restore content only.

FAQ

Is CVE-2025-24893 really “actively exploited”?

Yes. Multiple independent reports (incl. VulnCheck Canaries) show live exploitation delivering coin-miners and other payloads; exploit modules and PoCs are public.

Which versions are safe?

Per vendor/plugin advisories, upgrade to ≥15.10.11 (LTS) or ≥16.4.1 (stable). Some sources also reference 16.5.0-RC1 as including the fix

What other XWiki RCEs should we sanity-check?

If you are far behind, review 2024–2023 RCE advisories (e.g., registration feature RCE; earlier rendering/database search bugs) as part of the audit. 

Sources

• NVD entry for CVE-2025-24893 (SolrSearch macro → unauth RCE). 
• Tenable plugin details incl. fixed versions (≥15.10.11 / ≥16.4.1). 
• VulnCheck “Exploited in the Wild” analysis; two-stage chain & indicators. 
• SecPod & media coverage on active exploitation and coin-mining outcomes. 
• OffSec write-up of the flaw mechanics. 
• XWiki security advisories on RCE via registration/rendering contexts (background hardening). 
• Exploit modules / public PoCs (risk awareness only). 

CyberDudeBivash — Services, Apps & Ecosystem

• Rapid Vulnerability Response (webapp RCE triage, containment, patch orchestration)
• Detection Engineering (WAF/Suricata rules, app logs analytics, EDR/KSP hunts)
• IR Retainers (forensic triage, clean rebuilds, key rotation, post-incident hardening)

Apps & Products · Consulting & Services · ThreatWire Newsletter · CyberBivash (Threat Intel) · News Portal · CryptoBivash