2026年1月，OPSWAT 发布了 关于CVE-2025-66516的分析报告，该漏洞是Apache Tika中一个由恶意PDF触发、导致其到达后端解析器时引发的严重漏洞 ，该漏洞由恶意PDF文件到达后端解析器时触发。修复方案十分简洁：在文件到达解析器之前对其进行安全处理，从而确保解析器永远不会接触到有效载荷。之所以能奏效，是因为当时仅存在一个解析器、一种文件类型以及一个已知的库。
那么，如果该 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 哈希值。安全团队可借助完整的审计日志进行合规性审查和事件重构，而无需重新检查原始文件。
有关 XML 注入、CDATA 注入、XML 炸弹及相关 XML 攻击机制的完整说明，请参阅我们的 关于XML文档攻击向量的技术深度解析。
保护您的 XML 文件工作流
当一个值得信赖的解析器遇到恶意XML文件时，文件往往占上风。Apache Tika、Atlassian Crowd、IBM BAW以及SVG解析路径，都从文档处理管道、身份识别平台和工作流引擎等不同领域印证了这一点。
这些文件不会被视为威胁。它们来自已知的合作伙伴，通过既定的工作流程传输，且包含合法内容，这正是它们之所以有效的原因。针对不同CVE的修复方案并无二致：在传输层进行拦截，在文件到达解析器之前进行清理，并确保防护范围涵盖外部XML数据文件，而不仅仅是电子邮件附件和网页上传文件。
