CVE-2024-31982: XWiki unauthenticated remote code execution via database search
The short version: CVE-2024-31982 is a remote code execution flaw in XWiki's database search. Because that search is reachable by any visitor by default, an unauthenticated attacker can inject code through the search text and run it on the server. It scores 9.8, the technique is public, and it affects a wide range of XWiki versions. Upgrade or remove the affected search page. Steady hands — but patch.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | Moderate — in practice (see below) |
| 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 (XWiki/GitHub CNA scored 10.0, S:C) |
| EPSS | 34.28% · 98.23th percentile (2026-07-17) |
| In CISA KEV? | No — not listed at time of writing |
| Known exploited? | Not confirmed in the wild; a public exploit path exists |
| Vulnerability type | CWE-94 / CWE-95 code / eval injection → unauthenticated remote code execution |
| Requires authenticated session? | No — the database search is accessible to all users by default |
| Affected | XWiki Platform from 2.4-milestone-1, before 14.10.20, 15.5.4, and 15.10-rc-1 |
| Fixed in | XWiki 14.10.20 · 15.5.4 · 15.10-rc-1 (and later) |
What you need to know
XWiki is an open-source wiki platform. CVE-2024-31982 lives in its database search: the search text is evaluated in a way that lets an attacker inject and execute code (an async/Groovy macro) on the server. Because the database search page is, by default, reachable by any visitor of a public wiki — or any user of a closed one — the flaw is effectively unauthenticated.
Why it deserves attention:
- It's pre-authentication and internet-reachable. Public wikis are meant to be browsed by anyone, so the default configuration exposes the vulnerable endpoint.
- It's code execution, not just data access. A successful injection runs on the server, which can lead to full compromise of the XWiki host.
- The method is public. Proof-of-concept requests are documented, which lowers the bar for opportunistic use.
How serious we see it
Moderate — serious, with an honest caveat on the "Critical" band.
The mechanics justify the 9.8: unauthenticated, network-reachable code execution. We land on High rather than Critical because, at time of writing, it isn't in CISA KEV and we have no confirmation of widespread in-the-wild exploitation — which is the line we hold between "very bad and eminently reachable" and "actively being used against everyone." (Its close cousin, CVE-2025-24893 in XWiki's Solr search, is KEV-listed — treat that one as Critical.) The reassuring part: the fix is published, the affected range is well-defined, and if you don't use database search you can simply remove the page.
Recommendations
Straight from the XWiki security advisory (GHSA-2858-8cfx-69m9):
- Upgrade now. Move to XWiki 14.10.20 / 15.5.4 / 15.10-rc-1 or later.
- If you can't upgrade immediately, remove the page. Unless your users rely on database search, the affected page can be deleted — it isn't XWiki's default search interface.
- Hunt if you were exposed. Review web and application logs for suspicious requests to the database-search endpoint and for signs of injected macros.
- If compromised, respond. Rebuild the host, rotate any secrets XWiki held, and review connected systems.
- Confirm your exposure first. Verify whether you run an affected XWiki version and whether the search endpoint is reachable.
How BreachRisk sees it
BreachRisk discovers internet-facing XWiki instances in your external footprint and fingerprints the version, flagging exposure tied to this flaw. Because it's an unauthenticated, remotely checkable issue, BreachRisk can go a step beyond version-matching and safely confirm whether the exposed endpoint actually responds as vulnerable — a bounded, benign check rather than a weaponized payload. That's the honest difference between "this instance runs an affected version" and "we confirmed the vulnerable endpoint is reachable and responding."
A continuous, attacker's-eye view means a forgotten public wiki running an old XWiki build surfaces as a verified finding before someone else finds it first.