XML external entity (XXE) injection: how it works, how testers prove it, how to fix it

XML external entity (XXE) injection is a flaw where an XML parser processes entity references that point outside the document, so the server reads local files or makes network requests that an attacker chose. MITRE describes CWE-611 as a product that processes an XML document containing entities with URIs that resolve to documents outside the area the product intends to control. XXE usually comes from parser defaults or settings, not from application logic.

Testing for XXE is part of web application penetration testing and API penetration testing. Testing needs written authorization from the system owner.

What is XXE and why does an XML parser read files?#

An XML parser reads files because XML allows a document type definition (DTD) that can declare entities, and an entity can name an external resource by URI. When the parser expands such an entity, it fetches the resource and puts the content into the document.

That feature was designed for document assembly. It becomes a flaw when an application parses XML from an untrusted source with these features on. The three outcomes PortSwigger lists are reading files from the server, forcing the server to send requests (SSRF), and blind variants where the data is carried out of band. A fourth, resource exhaustion, comes from entity expansion.

OWASP merged XXE into Security Misconfiguration in the 2021 Top 10. In the Top 10:2025, security misconfiguration is A02.

How does an XXE attack work?#

An XXE attack works by sending an XML body that declares an external entity and then references it where the application echoes or uses the value. The parser expands the entity before the application sees the data.

// Vulnerable: default parser settings, untrusted body
DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document doc = db.parse(request.getInputStream());
String customer = doc.getElementsByTagName("customer").item(0).getTextContent();
return Map.of("customer", customer);

<invoice><customer>Acme Ltd</customer></invoice>

<!DOCTYPE invoice [ <!ENTITY probe SYSTEM "file:///srv/app/test-marker.txt"> ]>
<invoice><customer>&probe;</customer></invoice>

This is the pattern OWASP and PortSwigger document. For a case where the response never shows the value, see the blind section below.

What are the main XXE variants?#

XXE has a handful of variants, and they differ in what the attacker sees and what the server does. The table maps each to its evidence and to the usual fix.

XXE and SSRF overlap. XXE is a parser flaw that can cause SSRF. SSRF is a request-making flaw that can come from many features, including XML parsing.

Where is the hidden XXE attack surface?#

XXE hides wherever an XML parser sits behind a feature that does not look like XML. PortSwigger lists three common places: file uploads that parse XML formats, endpoints that accept XML if the content type is changed, and parameters that are inserted into a server-side XML document.

The Apache POI case below shows the Office-file route. File upload flaws and XXE often appear in the same test.

Which real incidents involved XXE?#

XXE has produced many CVEs in widely used libraries. Three records, each checked on NVD on 9 November 2026:

The three show different routes in: a database function, a web framework binding and an Office-file converter. None needed the application developer to write XML code.

How do penetration testers detect and prove XXE?#

Testers prove XXE with a harmless file or a callback, a control, and a saved response. Excession Labs holds to one evidence rule: a finding needs evidence of a real effect, and a bare "success" response is not proof.

1. Find every XML entry point: direct XML bodies, uploads of SVG and Office files, SAML, SOAP, feeds, and endpoints that accept a changed Content-Type.
2. Send a baseline request, then a control with a harmless DOCTYPE and no entity reference. Note whether the server rejects DOCTYPE, which is a good sign.
3. Declare an entity for a harmless file that the team placed for the test, or for a URL on a host the tester owns. Reference it in a field the response echoes.
4. For blind cases, use an out-of-band lookup to the tester's host and record the timestamp and source address.
5. Stop at the harmless proof. Do not read configuration files, keys or user data. Do not request cloud metadata unless the written scope approves it.
6. Keep the request, the response and the listener log. Report the controls that held, such as an endpoint that rejects DOCTYPE.

When a control shows the first result was misleading, we downgrade or drop the finding. Entity-expansion tests can harm availability, so run them only if the scope approves a bounded test.

How do you prevent XXE?#

Prevent XXE by disabling DTD processing in every parser that handles untrusted XML. If your application needs DTDs, disable external entities and external DTD loading instead. OWASP's cheat sheet gives per-parser settings and prefers rejecting DOCTYPE.

Java

DocumentBuilderFactory dbf = DocumentBuilderFactory.newDefaultInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
DocumentBuilder db = dbf.newDocumentBuilder();

The OWASP cheat sheet shows newDefaultInstance() for Java 9 and later. Set the features before you create the builder.

Python

import defusedxml.ElementTree as ET
root = ET.fromstring(xml_text, forbid_dtd=True)

# or with lxml
from lxml import etree
parser = etree.XMLParser(resolve_entities=False, no_network=True, load_dtd=False)
root = etree.fromstring(xml_bytes, parser)

The lxml FAQ says lxml 5.x disables external entity expansion by default. Setting the options explicitly keeps the behavior if you upgrade or downgrade.

PHP

// PHP 8.0 and later: libxml 2.9+ does not load external entities by default.
// Do not pass LIBXML_NOENT, LIBXML_DTDLOAD or LIBXML_DTDVALID.
$dom = new DOMDocument();
$dom->loadXML($xml, LIBXML_NONET);

// Extra layer (OWASP): the callback must return null
libxml_set_external_entity_loader(function () { return null; });

The PHP manual says libxml_disable_entity_loader has been deprecated since PHP 8.0.0 because external entity loading is disabled by default. On PHP before 8.0 with an old libxml, call it with true. OWASP warns that passing null directly to libxml_set_external_entity_loader() does not block loading. Use the callback form.

C# and .NET

var settings = new XmlReaderSettings {
    DtdProcessing = DtdProcessing.Prohibit,
    XmlResolver = null
};
using var reader = XmlReader.Create(stream, settings);

OWASP says XmlReader, XElement and XDocument are safe by default in any .NET version, and that XmlDocument and XmlTextReader are safe from .NET 4.5.2. A reader becomes unsafe only if DtdProcessing is Parse and a non-null resolver is set. In ASP.NET, the httpRuntime target framework must be 4.5.2 or later.

Node.js

// libxmljs: do not enable entity substitution for untrusted input
const doc = libxmljs.parseXml(xml, { noent: false, nonet: true });

Check the documentation of your XML library for its entity and network options. Prefer JSON for new endpoints. If you accept uploads that contain XML, parse them in a separate low-privilege process.

Beyond parser settings, add layers: update XML libraries, reject unexpected Content-Type values, validate and size-limit input, block outbound network access from the parsing service, and show generic error messages.

What is the XXE testing checklist?#

Use this list for each XML entry point, and only inside the agreed scope.

1. List every endpoint, upload and import that may reach an XML parser, including SVG, DOCX, XLSX, SAML, SOAP and feeds.
2. Test a changed Content-Type on JSON endpoints.
3. Send a baseline, a harmless DOCTYPE with no entity, and a nonexistent-file control.
4. Declare an entity for a harmless test file or a callback host, and reference it in an echoed field.
5. Test blind: a callback host with a timestamp and source address.
6. Test XInclude where only a value is controllable.
7. Check error messages for paths and parser names.
8. Stop at the harmless proof. Do not read secrets, and do not run expansion tests without written approval.
9. Save requests, responses and listener logs. Report the controls that held.
10. Review the code for parser creation calls that lack the settings in the table above.

When should you get a professional test?#

Get a professional test when your application accepts XML in any form: SOAP, SAML single sign-on, SVG or Office uploads, feed imports. XXE hides in libraries and in file handling that code review often misses. Blind and file-based cases need a callback listener and careful scope rules.

Excession Labs runs authorized web application penetration tests and API penetration tests. We agree the scope with you in writing, check the evidence for each finding and write the report. You can also apply for the free pentest pilot.