CVE-2025-24893: XWiki unauthenticated RCE via SolrSearch, actively exploited
The short version: CVE-2025-24893 lets any unauthenticated guest achieve remote code execution on an XWiki server through a single request to the SolrSearch endpoint. It scores 9.8, it's in CISA's Known Exploited Vulnerabilities catalog, and its EPSS sits near the top of the scale — meaning real, active exploitation. If you run an internet-facing XWiki, this is patch-and-verify, now. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice and on paper |
| CVSS v3.1 (NVD) | 9.8 — Critical · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | 99.90% · 99.97th percentile (2026-07-17) |
| In CISA KEV? | Yes — added 2025-10-30, remediation due 2025-11-20 |
| Known exploited? | Yes — active in-the-wild exploitation reported |
| Vulnerability type | CWE-94 / CWE-95 code / eval injection → unauthenticated remote code execution |
| Requires authenticated session? | No — reachable by any guest |
| Affected | XWiki Platform from 5.3-milestone-2, before 15.10.11; and 16.0.0-rc-1 before 16.4.1 |
| Fixed in | XWiki 15.10.11 · 16.4.1 · 16.5.0-rc-1 (and later) |
What you need to know
XWiki is an open-source wiki platform. CVE-2025-24893 lives in the SolrSearch feature: user-controlled search text supplied to the RSS output path is rendered by XWiki's engine without proper isolation, so an attacker can embed a macro (for example, {{groovy}}) that executes on the server. The whole attack is a single unauthenticated GET request — no account, no interaction.
Why it's top-of-queue:
- It's trivially reachable and pre-authentication. Any guest can hit the endpoint; the exploit is a crafted URL.
- It's full code execution. Success compromises the confidentiality, integrity, and availability of the entire XWiki installation.
- It's being used right now. CISA added it to KEV, and its EPSS is near the maximum — this is operational, not theoretical.
How serious we see it
High — the 9.8 and the real world agree.
Unauthenticated, single-request code execution on an internet-facing application, confirmed exploited and KEV-listed, is exactly what belongs at the top of the queue. The bounded, reassuring part is that it's narrow and fixable: the affected version range is well-defined, patched releases are available, and a documented workaround exists for teams that can't upgrade immediately. The catch is the usual one for an actively exploited flaw — if your instance was reachable before you patched, assume it may have been reached, and hunt.
Recommendations
Straight from the XWiki security advisory (GHSA-rr6p-3pfg-562j) and CISA:
- Patch now. Upgrade to XWiki 15.10.11 / 16.4.1 / 16.5.0-rc-1 or later.
- If you can't patch immediately, apply the vendor workaround. The advisory documents a change to the SolrSearch macro that neutralizes the flaw.
- Hunt. Review logs for requests to the SolrSearch RSS endpoint carrying macro payloads, and for signs of code execution.
- If compromised, respond. Rebuild the host, rotate secrets XWiki held, and investigate connected systems.
- Confirm your exposure first. Verify whether you run an affected XWiki version and whether SolrSearch is reachable.
How BreachRisk sees it
BreachRisk discovers internet-facing XWiki instances from little more than your domain and fingerprints the version, flagging exposure tied to this KEV-listed, actively exploited flaw — pushed to the top of your results because it's in KEV. Because it's an unauthenticated, remotely checkable issue, BreachRisk can go beyond version-matching and safely confirm whether the exposed endpoint responds as vulnerable, as a bounded check rather than a weaponized attack — the difference between "runs an affected version" and "confirmed reachable and responding."
That continuous, attacker's-eye view is the whole point for a flaw like this: an exposed XWiki is already mapped and ranked by how it actually gets used against you, so you can go straight to patch-and-verify.