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.
Now what if the XML is not a PDF, but a configuration file imported into an SSO (Single Sign-On) platform, a workflow definition sent to a financial automation engine, or a health data payload processed by a hospital integration system? These files move between organizations, contractors, regulators, and partners every day, arriving through managed file transfer and partner portals as trusted business inputs. Most sanitization solutions never inspect them.
XML Is the Language of Industry, and That Is the Problem
PDF and SVG XXE (XML External Entity) attacks share a shape: a user uploads a file; a backend library parses it; the parser executes the payload. The entry point is visible.
Industry XML is different. They are business-to-business transfers, configuration imports, and system-to-system payloads from known partners, regulators, contractors, and vendors. That apparent legitimacy is exactly why they bypass the scrutiny applied to web uploads.
XML is embedded in how many industries operate:
- Financial services: SWIFT messaging, FIX (Financial Information eXchange) instructions, and ISO 20022 payments are all XML.
- Healthcare: HL7 (Health Level Seven) and FHIR (Fast Healthcare Interoperability Resources), the standard health data exchange protocols, are XML-based. A malicious entity in a FHIR payload passes through any system that checks structure but not the DOCTYPE.
- Enterprise IT: Identity and SSO platforms ingest XML configuration files during integration, migration, and onboarding. One import can reach every application the platform authenticates.
- OT: SCADA and energy management systems exchange data in XML formats defined by IEC 61968 and 61970, often across IT/OT boundaries where controls are minimal.
In every case, the payload is not a script or a macro but exists in the content layer of the XML: a DOCTYPE declaration referencing an external entity that points to a local file path or an internal endpoint. When the parser processes the file, it fetches that content.
While the file is structurally valid under schema check, its content requires a deeper level of sanitization, e.g. what the DOCTYPE declares or where the entity points.
This Is Not a Legacy Problem
XXE was described in 2003 and added to the OWASP Top 10 in 2017, which sometimes leads teams to treat it as solved. The 2025 and 2026 record says otherwise, and the cases that matter for file security are the ones where the payload arrives as a file.
- lxml (CVE-2026-41066): the default parser config in a widely used Python XML library let untrusted XML read local files. lxml is the same library svglib uses to parse SVG (Scalable Vector Graphics) files, the file-borne path OPSWAT demonstrated in its 2024 SVG XXE blog. Sanitizing the file removes the entity before the parser sees it.
- Atlassian Crowd (CVE-2026-21569, CVSS 7.9 High): an SSO and identity platform. A crafted XML payload gives an attacker local or remote file access, and the CVSS Scope:Changed rating means a successful exploit reaches every application Crowd authenticates. The XML arrives as a configuration or integration import from a partner or admin workstation.
- IBM Business Automation Workflow (CVE-2025-13096, CVSS 7.1 High): IBM BAW processes XML in workflows like loan origination and claims processing. The flaw allows file disclosure and SSRF (Server-Side Request Forgery), letting an attacker pivot to internal endpoints, and the same DOCTYPE structure can drive entity expansion for DoS (Denial of Service). The XML arrives through partner portals from adjusters, regulators, and integrators.
All point to one common shape: a trusted business XML file carrying a DOCTYPE payload, arriving through an established workflow before it reaches a vulnerable parser.
One scope note: this blog discusses XXE that arrives as a file. XML, and XML-based formats like SVG, PDF with XFA, and Office files, that pass through a sanitization workflow are reconstructed clean. The file-borne cases are the common ones: uploads, configuration imports, partner data exchange, and email attachments. XXE reached through a raw API request body or an in-code parsing call has no file in transit, so a file-sanitization gateway does not sit in that path.
How Deep CDR™ Technology Handles Standalone XML Files
Deep CDR™ Technology supports XML 1.0 and 1.1, plus related XML-based formats including ZEI, JNLP, TDS, RDF, BML, MPD, and TTML under the same engine.
For XML files, references that point outside the document are refused by default, and the DOCTYPE and its external entity references do not survive into the reconstructed file. Neither behavior is a policy that has to be found and tuned. As long as external XML is routed through the sanitization workflow in MetaDefender Core™, the protection applies.
On top of this default DOCTYPE stripping, operators have additional controls they can configure to match their environment
- Remove Macro: strips VBA macros encoded in XML-based Office formats
- Remove CDATA: four graduated policy options, from "Do nothing" through "Remove all," giving teams control over how aggressively CDATA sections are handled depending on the sensitivity of the workflow
- Remove Injection: addresses XML injection and content-layer JavaScript embedded in element values
- Process Base64 encoded data: handles encoded payloads embedded in XML values, including data URL scheme patterns
A related protection covers the other side of the same direction. Structures written to expand until they exhaust memory are detected and removed, so a small file cannot become an enormous one on the way through, which was how the name XML Bomb (or Billion Laughs) is referred to for such reason.
Every sanitization action is captured in a forensic JSON report. The report includes the object name, the removed content (capped at 5,000 characters per entry), and the SHA-256 hash of the removed object. Security teams have a complete audit trail for compliance review and incident reconstruction without needing to re-examine the original file.
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.
Protect Your XML File Workflows
When a trusted parser meets a malicious XML file, the file wins. Apache Tika, Atlassian Crowd, IBM BAW, and the SVG parsing path all prove the point across document pipelines, identity platforms, and workflow engines.
These files are not treated as threats. They come from known partners through established workflows and carry legitimate content, which is what makes them effective. The fix does not change from one CVE to the next: intercept at the transfer layer, sanitize before the file reaches the parser, and ensure protection covers external XML data files, not just email attachments and web uploads.
