In January 2026, OPSWAT published analysis of CVE-2025-66516, a critical vulnerability in Apache Tika triggered by a malicious PDF reaching a backend parser. The fix was clean: sanitize the file before it reaches the parser, and the parser never sees the payload. That worked because there was one parser, one file type, and one known library.
那么，如果该 XML 文件不是 PDF，而是导入到单点登录（SSO）平台中的配置文件、发送至财务自动化引擎的工作流定义，或是由医院集成系统处理的医疗数据负载呢？这些文件每天都在组织、承包商、监管机构和合作伙伴之间流转，通过受管文件传输和合作伙伴门户作为可信的业务输入传入。大多数数据净化解决方案从未对其进行过检查。
XML 是行业的通用语言，而这正是问题所在
PDF 和 SVG 的 XXE（XML 外部实体）攻击具有相同的攻击模式：用户上传文件；后端库对其进行解析；解析器执行有效载荷。攻击入口显而易见。
行业 XML 则有所不同。它们是来自已知合作伙伴、监管机构、承包商和供应商的企业间数据传输、配置导入以及系统间数据负载。正是这种表面上的合法性，使得它们得以绕过针对网页上传所实施的审查。
XML已融入许多行业的运作之中：
- 金融服务：SWIFT 报文、FIX（金融信息交换）指令以及 ISO 20022 支付均采用 XML 格式。
- 医疗保健：HL7（Health Level Seven）和FHIR（Fast Healthcare Interoperability Resources）作为标准的医疗数据交换协议，均基于XML。FHIR有效载荷中的恶意实体能够绕过任何仅检查结构而不检查DOCTYPE的系统。
- 企业 IT：身份识别和单点登录（SSO）平台在集成、迁移和接入过程中会导入 XML 配置文件。一次导入即可覆盖该平台所认证的所有应用程序。
- OT：SCADA 和能源管理系统按照 IEC 61968 和 61970 标准定义的 XML 格式交换数据，这种数据交换通常发生在 IT/OT 边界之间，而该区域的控制措施往往较为有限。
在所有情况下，有效载荷都不是脚本或宏，而是存在于XML的内容层中：一个DOCTYPE声明引用了一个外部实体，该实体指向本地文件路径或内部端点。当解析器处理该文件时，它会获取该内容。
虽然该文件在模式检查中结构上有效，但其内容需要进行更深入的清理，例如 DOCTYPE 的声明内容或实体所指向的位置。
这并非一个历史遗留问题
XXE 漏洞于 2003 年被首次描述，并于 2017 年被列入OWASP 前十大漏洞，这有时会导致团队将其视为已解决的问题。但 2025 年和 2026年的记录表明情况并非如此，而对于文件安全而言，真正需要关注的情况是有效载荷以文件形式到达的情形。
- lxml (CVE-2026-41066)：一款广泛使用的 Python XML 库中的默认解析器配置，允许不受信任的 XML 读取本地文件。lxml 正是 svglib 用于解析 SVG（可缩放矢量图形）文件的库，其 2024 年 SVG XXE 博客中演示的通过文件传播的路径即为OPSWAT 。对文件进行清理可确保在解析器识别该实体之前将其移除。
- Atlassian Crowd（CVE-2026-21569，CVSS 7.9 高）：一款单点登录（SSO）和身份管理平台。经过特殊构造的 XML 有效载荷可使攻击者获得本地或远程文件访问权限，且 CVSS 评分中的“范围：已更改”（Scope:Changed）评级意味着，一旦成功利用该漏洞，攻击将波及所有由 Crowd 进行身份验证的应用程序。该 XML 通常以配置文件或集成导入的形式，从合作伙伴或管理员工作站传入。
- IBM 业务自动化工作流（CVE-2025-13096，CVSS 7.1 高）：IBM BAW 在贷款发放和理赔处理等工作流中处理 XML。该漏洞会导致文件泄露和 SSRF（Server-Side Request Forgery，服务器端请求伪造），使攻击者能够跳转至内部端点；此外，相同的 DOCTYPE 结构还可能引发实体展开，从而导致 DoS（拒绝服务）攻击。 这些 XML 数据通过合作伙伴门户从理赔员、监管机构和系统集成商处传入。
所有迹象都指向一种共同的形式：一个包含 DOCTYPE 有效载荷的可信商业 XML 文件，在到达存在漏洞的解析器之前，会先经过既定的处理流程。
一项范围说明：本文 讨论的是以文件形式传播的XXE。XML以及基于XML的格式（如SVG、包含XFA的PDF和Office文件），只要经过净化处理流程，就能被重建为干净的文件。 文件传播的案例最为常见：包括文件上传、配置导入、合作伙伴数据交换以及电子邮件附件。而通过原始的API 请求正文或代码内的解析调用实现的 XXE 攻击，在传输过程中不涉及文件，因此该路径上不会存在文件净化网关。
Deep CDR™ 技术如何处理独立的 XML 文件
Deep CDR™ 技术在同一引擎下支持 XML 1.0 和 1.1，以及基于 XML 的相关格式，包括 ZEI、JNLP、TDS、RDF、BML、MPD 和 TTML。
对于 XML 文件，默认情况下会拒绝指向文档外部的引用，且 DOCTYPE 及其外部实体引用不会保留在重建后的文件中。
这两种行为都不属于需要查找和调整的策略。只要外部 XML 通过MetaDefender Core™ 中的净化工作流进行处理，保护机制就会生效。
除了这种默认的 DOCTYPE 过滤功能外，运算符还可以配置其他控制选项，以适应其运行环境
- “移除宏”：清除基于 XML 的 Office 格式中编码的 VBA 宏
- 删除 CDATA：提供四种渐进式的策略选项，从“不采取任何操作”到“全部删除”，让团队能够根据工作流的敏感程度，灵活控制处理 CDATA 片段的严格程度
- 消除注入：解决 XML 注入以及嵌入在元素值中的内容层 JavaScript 问题
- 处理 Base64 编码的数据：处理嵌入在 XML 值中的编码有效载荷，包括数据 URL 方案模式
一项相关的防护措施还涵盖了同一方向的另一面。系统会检测并清除那些设计为不断扩展直至耗尽内存的结构，因此一个小文件在处理过程中无法变成一个巨型文件——正因如此，这种攻击才被称为“XML炸弹”（或“十亿次笑”）。
每次数据清理操作都会被记录在一份取证级 JSON 报告中。该报告包含对象名称、已删除的内容（每条记录上限为 5,000 个字符）以及已删除对象的 SHA-256 哈希值。安全团队可借助完整的审计日志进行合规性审查和事件重构，而无需重新检查原始文件。
For a full explanation of XML injection, CDATA injection, XML bombs, and related XML attack mechanics, see our technical deep dive on XML document attack vectors.
保护您的 XML 文件工作流
当一个值得信赖的解析器遇到恶意XML文件时，文件往往占上风。Apache Tika、Atlassian Crowd、IBM BAW以及SVG解析路径，都从文档处理管道、身份识别平台和工作流引擎等不同领域印证了这一点。
这些文件不会被视为威胁。它们来自已知的合作伙伴，通过既定的工作流程传输，且包含合法内容，这正是它们之所以有效的原因。针对不同CVE的修复方案并无二致：在传输层进行拦截，在文件到达解析器之前进行清理，并确保防护范围涵盖外部XML数据文件，而不仅仅是电子邮件附件和网页上传文件。
