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 Top 10，這有時會導致團隊誤以為該漏洞已獲得解決。然而，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 Business Automation Workflow（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 資料檔案，而不僅限於電子郵件附件和網頁上傳檔案。
