CVE-2025-24893

What it actually does

CVE-2025-24893 is an unauthenticated remote code execution vulnerability in XWiki’s SolrSearch functionality. A guest user can send a crafted request to the SolrSearch endpoint that causes attacker-supplied XWiki rendering content, such as executable macros, to be evaluated in a privileged server-side context. Successful exploitation allows arbitrary code execution on the XWiki application server, which can lead to command execution, file access, credential theft, data modification, persistence, and full compromise of the XWiki installation.

Why it matters to the business

Because exploitation requires no login and the vulnerability is known to be actively exploited in the wild with a very high EPSS probability, internet-facing XWiki systems should be treated as high-priority exposure. A successful compromise can result in theft or destruction of wiki content, exposure of secrets stored in pages or configuration files, defacement, service outage, lateral movement from the application server, and deployment of malware or botnet tooling. The vulnerability is listed in CISA KEV with a remediation due date of 2025-11-20, increasing urgency for organizations subject to KEV-driven remediation policies.

How an attack unfolds

An attacker identifies an exposed XWiki instance and sends an unauthenticated HTTP request to the SolrSearch endpoint, commonly under paths such as /xwiki/bin/get/Main/SolrSearch or /bin/get/Main/SolrSearch. The request includes crafted search parameters that are rendered by the server, causing injected XWiki markup or macros to execute instead of being treated as plain search input. Public exploitation has used macro-oriented payloads, including asynchronous and Groovy-style constructs, to validate execution and then run operating-system commands. After confirming code execution, an attacker may download and run malware, establish a reverse shell, create persistence, read XWiki configuration and attachment data, steal database credentials, modify pages, or use the compromised server for botnet activity. Reported exploitation context includes RondoDox activity and broader exploitation of the XWiki Platform eval injection vulnerability.

How to fix it

Upgrade affected XWiki-derived deployments to fixed builds immediately. For the packages provided: upgrade hubble-ui-backend (Bitnami) to 1.11.15 or later; ensure xwiki/xwiki-platform includes commit 67021db9b8ed26c2236a653269302a86bf01ef40 or a later fixed release; ensure xwiki/xwiki-commons includes commit 19099ac5630b3ac7fe63653880853d04e2cbcfc1 or a later fixed release. If using packaged XWiki distributions, apply the vendor-supported version that contains the fix rather than only cherry-picking code where possible. Until upgraded, restrict unauthenticated access to XWiki and especially SolrSearch routes using network controls, reverse-proxy rules, or application-layer access controls. Block requests to SolrSearch containing executable macro markers such as encoded or decoded {{groovy}}, {{velocity}}, {{async}}, or similar XWiki macro syntax. After patching, rotate credentials and secrets accessible to the XWiki application if exploitation is suspected, including database credentials, API tokens, mail credentials, LDAP bind credentials, and administrative passwords.

How to confirm the fix worked

Confirm the running deployment is a fixed version or contains the listed fixed commits. Verify the package inventory shows hubble-ui-backend 1.11.15 or later where applicable, and confirm XWiki platform and commons code includes the specified fixed commits or a vendor release incorporating them. From an unauthenticated session, confirm that SolrSearch remains reachable only as intended and that search parameters are treated as plain input rather than rendered executable content. Review reverse-proxy, WAF, and application logs for prior requests to Main/SolrSearch containing encoded or decoded macro syntax. If exposure existed before patching, perform host-level validation for unexpected child processes spawned by the XWiki Java process, new files in temporary directories, suspicious outbound connections, unknown scheduled tasks, and unauthorized changes to XWiki pages, users, groups, or configuration.

Typical attack path

1. Scan the internet or target ranges for exposed XWiki installations.
2. Probe likely XWiki routes, especially SolrSearch endpoints reachable without authentication.
3. Send a crafted request to SolrSearch with encoded XWiki macro or script-like content in a request parameter.
4. Confirm server-side execution through command output, timing behavior, callbacks, or distinctive response content.
5. Execute follow-on commands to download tooling, open a shell, enumerate the application host, or read XWiki configuration files.
6. Use stolen configuration secrets or database credentials to access wiki data and supporting infrastructure.
7. Persist, exfiltrate content, modify pages, deploy malware, or use the host for further attacks.

How to detect it

Review web server, reverse-proxy, WAF, load balancer, and XWiki application logs for unauthenticated requests to SolrSearch, especially /xwiki/bin/get/Main/SolrSearch or /bin/get/Main/SolrSearch with media=rss, text=, or encoded macro syntax. Look for decoded or URL-encoded XWiki macro markers such as {{async}}, {{groovy}}, {{velocity}}, {{/groovy}}, and attempts to break out of markup with }}} before macro execution. Correlate suspicious HTTP requests with application-server behavior: Java processes spawning /bin/sh, bash, curl, wget, python, perl, nc, busybox, chmod, or other utilities; creation of files in /tmp, /var/tmp, or the XWiki data directory; and unexpected outbound connections shortly after the request. Inspect XWiki audit logs and page history for unauthorized administrative changes, new users, group membership changes, modified pages containing macros, or unexpected attachments. For confirmed or suspected exploitation, collect access logs, application logs, JVM logs, process execution telemetry, shell history, temporary directories, cron/systemd entries, and network flow records. Given reported RondoDox exploitation, also hunt for automated botnet-style post-exploitation: scripted download-and-execute chains, repeated architecture checks, unusual high-volume outbound traffic, or malware staging from disposable infrastructure.

• /xwiki/bin/get/Main/SolrSearch
• /bin/get/Main/SolrSearch
• Main/SolrSearch?media=rss
• media=rss&text=
• %7B%7Bgroovy%7D%7D
• %7b%7bgroovy%7d%7d
• {{groovy}}
• %7B%7B%2Fgroovy%7D%7D
• %7b%7b%2fgroovy%7d%7d
• {{/groovy}}
• %7B%7Basync%20async%3Dfalse%7D%7D
• %7b%7basync%20async%3dfalse%7d%7d
• {{async async=false}}
• %7B%7B%2Fasync%7D%7D
• {{/async}}
• %7D%7D%7D%7B%7Basync
• }}}{{async
• %7B%7Bvelocity%7D%7D
• {{velocity}}
• %7B%7B%2Fvelocity%7D%7D
• {{/velocity}}
• SolrSearch%3Fmedia%3Drss
• java.lang.ProcessBuilder
• Runtime.getRuntime
• /bin/sh -c
• bash -c
• wget http
• curl http

What your security team should do

• Patch or upgrade all affected XWiki deployments immediately, prioritizing internet-facing systems and systems reachable by untrusted users.
• Because the vulnerability is in CISA KEV and actively exploited with very high EPSS, treat unpatched public instances as likely targeted and investigate for compromise, not just exposure.
• Add temporary reverse-proxy or WAF controls blocking unauthenticated SolrSearch requests containing encoded or decoded XWiki macro syntax until patching is complete.
• Search historical HTTP logs for suspicious Main/SolrSearch requests, especially requests using media=rss, text parameters, or encoded {{async}} / {{groovy}} patterns.
• Review endpoint telemetry for Java spawning shell utilities, download tools, scripting interpreters, or unexpected network clients.
• If suspicious activity is found, isolate the server, preserve logs and disk artifacts, rotate XWiki-related secrets, and perform full incident response.
• Monitor for RondoDox-style botnet behavior, including automated exploitation attempts followed by wget/curl downloads, shell scripts, unusual outbound connections, or DDoS/miner tooling.
• Add continuous external attack-surface checks for exposed XWiki instances and verify that fixed versions remain deployed across downstream or embedded distributions.