XXE Guide: Preventing XML External Entity Vulnerabilities

An XML parser that honours document type definitions will fetch whatever an untrusted document tells it to, from local files to internal web services. That behaviour, XML External Entity (XXE) processing, is catalogued as CWE-611 and sits inside OWASP Top 10 2021 category A05 Security Misconfiguration, because in most cases the fix is a parser setting rather than a code rewrite. XXE keeps reappearing in the CISA Known Exploited Vulnerabilities (KEV) catalogue, in products from Adobe Commerce to GeoServer. This guide explains how the weakness works at a conceptual level, where XML hides in modern applications, how to detect it, and the exact secure parser settings for Java, .NET, PHP, Python, C and C++. It is written for application security engineers, developers and reviewers, and deliberately contains no attack strings.

Key takeaways

• XXE is a configuration flaw. The parser, not the business logic, resolves external entities; disabling DTD processing removes the whole class in most stacks.
• XML is in more places than your API. SAML assertions, SOAP services, SVG images, Office documents, RSS feeds and document converters all parse XML, often through a library you did not configure.
• Defaults differ by language and version. .NET 4.5.2 and later, libxml2 2.9 and later, and lxml 5.x are safe by default for external entities; Java JAXP factories are not.
• Impact goes beyond file reads. CWE-611 lists confidentiality loss, server-side request forgery style outbound requests and denial of service; NVD rates the Adobe Commerce XXE (CVE-2024-34102) 9.8 with possible code execution.
• Prove it with tests, not assumptions. A unit test per parser that feeds a document with a DTD and expects rejection catches regressions that code review misses.

How the attack works

XML 1.0 lets a document carry a document type definition (DTD). A DTD can declare entities: named placeholders the parser substitutes while it builds the document. An external entity points to a URI, and a permissive parser dereferences that URI and inlines the result. CWE-611 describes the weakness as a parser processing entities whose URIs resolve to documents outside the intended sphere of control. MITRE classes it as a child of CWE-610 (externally controlled reference to a resource in another sphere) and notes its close relationship to CWE-918 SSRF, because both make the server issue requests to destinations the attacker chooses.

• In-band XXE: the resolved content is reflected in the application's response, for example in an error message or an echoed field.
• Blind XXE: nothing is reflected. The OWASP Web Security Testing Guide (WSTG-INPV-07) notes that blind variants are confirmed through out-of-band interaction or error messages, so an application that "returns nothing" is not proven safe.
• Parameter entities: entities used inside the DTD itself. Several parsers control these with a separate switch from general entities, which is why disabling only one setting leaves a gap.
• Entity expansion denial of service: internal entities that reference each other (the "billion laughs" pattern, CAPEC-221 Data Serialization External Entities Blowup) or one large entity repeated many times (quadratic blowup) exhaust memory and CPU without any external resource at all.
• XInclude: a separate W3C mechanism that also pulls in external content. OWASP advises keeping it disabled even when entities are off.
• Second-order XXE: the XML is stored first (an uploaded file, a queued message, an imported feed) and parsed later by a back-end job, often with weaker settings and broader network access than the front end.

Where it shows up

The WSTG warns that a hardened primary API does not make other XML paths safe. Inventory every place your estate parses XML, including formats that do not look like XML to users.

Commercial software is a large share of the exposure. The KEV catalogue (local copy, October 2026) lists CWE-611 flaws in Adobe Commerce and Magento Open Source, SysAid On-Prem (CVE-2025-2775 and CVE-2025-2776), North Grid Proself, Zimbra Collaboration Suite, Citrix StoreFront Server, SAP NetWeaver and GeoServer. For these, the control is patch management rather than code change. See the Vulnerability Scanning Guide.

Impact

The outbound request path is the reason XXE belongs in the same review as SSRF. See the SSRF Prevention Guide.

Where identity fits

The most valuable files on an application server are usually machine credentials: database connection strings, API keys, service account key files and cloud role credentials reachable through instance metadata. An XXE file read is therefore frequently an NHI credential theft. Keep secrets out of readable files and short-lived where possible, so that a disclosed value expires before it can be reused. See the Secrets Management Guide.

Detection

• Static analysis: CWE-611 rates automated static analysis as highly effective. Configure SAST rules that flag parser factories created without the secure features below, and run them on every pull request.
• Configuration review: WSTG-INPV-07 recommends white-box review of parser settings across the codebase and its dependencies. Search for DocumentBuilderFactory, SAXParserFactory, XMLInputFactory, TransformerFactory, XmlDocument, LIBXML_NOENT and resolve_entities.
• Dynamic testing: include XXE checks (in-band and out-of-band) for every XML-accepting endpoint and every upload type that carries XML. See the Web Application Security Testing Guide.
• Dependency and product scanning: track CWE-611 advisories for XML libraries and for commercial products, prioritising KEV entries.
• Runtime signals: alert on application servers making unexpected outbound DNS or HTTP requests, on access to metadata endpoints from application processes, and on parser exceptions mentioning DOCTYPE or DTD. A WAF can log request bodies containing DOCTYPE declarations on endpoints that never legitimately receive them. See the Web Application Firewall Guide.

Metrics

• Parser coverage: percentage of XML parsing call sites with a verified secure configuration and a regression test.
• Open CWE-611 findings: count and age of open SAST, DAST and penetration test findings.
• KEV patch time: days from KEV listing to patch for CWE-611 product flaws, against the KEV due date.
• XML surface: number of endpoints accepting application/xml or XML-based uploads, trending down where XML is unnecessary.
• Egress exceptions: number of application workloads with unrestricted outbound internet access.

Prevention and hardening

OWASP's guiding rule: disable DTDs where possible, keep XInclude disabled, and treat any unsupported security setting as a failure rather than continuing with partial hardening.

Secure parser settings by platform

Decision guidance

• Do you need XML at all? If an endpoint can accept JSON only, remove XML binding. This is the cheapest and most complete fix.
• Disallow DTDs vs restrict them: disallowing DOCTYPE declarations is preferred because it also stops entity expansion denial of service. Choose the restrictive per-feature settings only when a legitimate format needs inline DTDs, and add entity expansion limits.
• Central wrapper vs per-call configuration: large codebases should expose one approved parser factory and ban direct factory construction through lint rules. Small teams can rely on the platform default where it is safe, plus a test.
• Library you do not control: check whether wrappers such as dom4j, JDOM or Commons Digester replace the reader's resolver, as OWASP warns. If a product is affected, patch and apply a WAF rule as a temporary measure.

Defence in depth

• Least privilege: run XML processing in a process or container that cannot read secrets and has no unnecessary file system access.
• Egress control: deny outbound connections from parsing workloads by default, and require tokens for cloud metadata services.
• Size limits: bound request size and decompressed size independently; Python's documentation names decompression bombs as a risk for any library parsing compressed streams.
• Patching: keep XML libraries current, since parser defaults and expansion limits have improved over time.

Rollout plan

1. Inventory: list every XML parsing call site, framework and product, using code search, SAST and the upload type list above.
2. Write failing tests first: for each parser, a unit test feeding a harmless document containing a DOCTYPE declaration and expecting rejection or no external access.
3. Apply the secure settings through a shared factory, starting with internet-facing and upload paths.
4. Pilot in staging with real partner and SAML traffic replayed, watching for legitimate documents that carry DTDs.
5. Roll out by service behind a configuration flag; if a partner format breaks, roll back that service only and switch it to the restrictive per-feature settings rather than re-enabling everything.
6. Lock in: enable SAST rules as blocking, add the tests to CI and record the standard in your secure coding baseline. See the Secure Coding Guide.

Framework mapping

Common failure patterns

• Fixing one factory and missing the rest: the DOM parser is hardened, but the XSLT, schema validator or StAX reader in the same service is not. WSTG-INPV-07 calls this out explicitly.
• Trusting an expand-entities flag: in Java, setExpandEntityReferences(false) changes tree representation only and does not block external resources, according to OWASP.
• Forgetting file formats: the JSON API is safe, but an SVG thumbnailer or DOCX text extractor parses uploaded XML with library defaults.
• Back-end jobs with more reach: second-order parsing in a batch worker that has wide egress and mounted credentials.
• Framework version mismatch: an ASP.NET application compiled for a modern framework but with httpRuntime targetFramework below 4.5.2 keeps the older, unsafe behaviour.
• Treating product XXE as low priority: KEV has listed multiple CWE-611 flaws with federal due dates; a medium internal rating does not reflect active exploitation.

Practitioner checklist

• Inventory every XML parser, XML-based upload type, SAML library and XML-consuming product.
• Remove XML support from endpoints that only need JSON.
• Disallow DOCTYPE declarations by default; where DTDs are required, disable external general entities, parameter entities, external DTD loading and XInclude separately.
• Provide one approved parser factory per language and ban direct construction through lint or SAST rules.
• Add a regression test per parser that expects a document with a DTD to be rejected.
• Set entity expansion and decompressed size limits, and keep libxml2, Expat and other XML libraries patched.
• Run parsing workloads with least privilege, default-deny egress and token-protected metadata access.
• Track CWE-611 KEV entries and patch affected products by the KEV due date.
• Monitor application servers for unexpected outbound DNS and HTTP and for DTD-related parser exceptions.

Standards and references

• OWASP: XML External Entity Prevention Cheat Sheet
• MITRE: CWE-611 Improper Restriction of XML External Entity Reference
• OWASP: Web Security Testing Guide, Testing for XML Injection
• OWASP: Application Security Verification Standard 5.0
• Microsoft Learn: XmlReaderSettings.DtdProcessing Property
• Python Software Foundation: XML Processing Modules, XML security
• NIST NVD: CVE-2024-34102
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Web Application Attacks Guide · SSRF Prevention Guide · Insecure Deserialisation Guide · CWE Top 25 Guide