2026年1月，OPSWAT 發布了 關於 CVE-2025-66516 的分析報告，這是 Apache Tika 中的 ，該漏洞是由惡意 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 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 雜湊值。安全團隊可藉此獲得完整的稽核軌跡，以便進行合規性審查與事件重構，而無需重新檢查原始檔案。
有關 XML 注入、CDATA 注入、XML 炸彈及相關 XML 攻擊機制之完整說明，請參閱我們的 關於 XML 文件攻擊向量的技術深度解析。
保護您的 XML 檔案工作流程
當一個值得信賴的解析器遇到惡意 XML 檔案時，惡意檔案往往佔上風。Apache Tika、Atlassian Crowd、IBM BAW 以及 SVG 解析路徑，皆在文件處理流程、身分識別平台和工作流程引擎等領域中印證了這一點。
這些檔案不會被視為威脅。它們是透過既定的工作流程，由已知的合作夥伴傳送而來，且包含合法內容，這正是它們之所以有效的關鍵。針對不同 CVE 的解決方案並無二致：在傳輸層進行攔截，在檔案送達解析器之前進行淨化處理，並確保防護範圍涵蓋外部 XML 資料檔案，而不僅限於電子郵件附件和網頁上傳檔案。
