When external entity resolution remains enabled, untrusted XML can make the parser disclose local files, reach internal services, or consume resources in ways the application never intended. The failure is not only technical parsing error. It is an unsafe trust decision that turns document handling into a route for data exposure and network abuse.
What XML parsers are actually trusting when they resolve external entities
External entity resolution is a parser feature that tells XML tooling to follow references outside the document itself. That can include local file paths, remote URLs, or other resolvable identifiers. Once that behaviour is left on for untrusted input, the parser is no longer just reading markup, it is acting on attacker-controlled instructions about where to fetch content.
That trust boundary matters because the parser often runs with the application’s network reach and file permissions. A document that looks harmless can therefore trigger file reads, internal HTTP requests, or outbound retrievals before the application has a chance to inspect the content.
How XXE turns parsing into disclosure and request forwarding
The classic failure mode is XML External Entity, where a hostile document defines an entity that points to sensitive local data or an internal service. If the parser resolves it, the expanded result can leak configuration files, environment details, or other secrets into logs, error messages, or response bodies. In some environments, the same mechanism can be used to make the server request internal-only endpoints.
That is why this issue sits close to trust-boundary handling, not just parser hardening. The application may believe it is processing a data file, while the parser is effectively being asked to dereference resources on the system’s behalf. A similar trust failure appears in other control frameworks that treat unauthorised outbound requests and access-path abuse as security defects, such as EU Digital Operational Resilience Act (DORA) and EU NIS2 Directive, which both emphasise resilience and controlled handling of system and third-party interactions.
External entity resolution can also become a blind SSRF-like primitive when the parser is allowed to contact URLs chosen by the attacker. Even if the response never returns to the user, the server has already crossed a boundary it should not have crossed. That makes the issue relevant to NIST SP 800-53 Rev 5 Security and Privacy Controls style access and integrity controls, because the defect is really about preventing unauthorised data flow and unauthorised resource access.
Why this becomes a resource-exhaustion problem as well as a data problem
Entity expansion is not only about disclosure. Malicious XML can also force the parser into repeated lookups, recursive resolution, or large intermediate expansions that consume memory, CPU, or network capacity. In other words, the same feature that creates data exposure can also become an availability problem when the parser spends effort following untrusted references.
That dual impact is what breaks the safe-use assumption. A parser that should be a passive decoder becomes an active fetch-and-expand engine. The application may see slow responses, timeouts, or opaque failures, but the root cause is often the same unsafe capability: untrusted XML is allowed to drive external resolution.
The practical control lesson is consistent with secure input handling guidance from NIST Privacy Framework and NIST Cybersecurity Framework 2.0: treat parser behaviour as part of your attack surface, not as a neutral library default. If the parser can reach out, the document can become a control input for side effects.
Risk and Threat Considerations
Leaving external entity resolution enabled creates a direct exposure path from untrusted XML into local files, internal network resources, and parser workload. The threat is attractive because it often requires only a crafted document and can succeed before higher-level application logic ever runs.
Failure mechanism: The parser expands attacker-controlled entities and follows file or URL references using its own execution context, which can disclose data or trigger internal requests.
Impact: Confidential information may leak, internal services may be probed from a trusted host, and parser processing may be abused for denial of service or noisy exploitation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | XXE abuse depends on the parser's ability to read or reach resources it should not access. |
| SI-10 — Information Input Validation | Untrusted XML is a hostile input that must not trigger unsafe parser behaviour. | |
| SC-7 — Boundary Protection | External entity resolution can cross network and trust boundaries through parser-initiated requests. | |
| Recommendation — Restrict parser runtime access to only the files and network targets it truly needs. Validate and constrain XML processing before the parser expands external references. Block parser-initiated access to internal services and unapproved outbound destinations. | ||
| OWASP API Security Top 10 | API7 — Server Side Request Forgery | Parser-followed external entities can coerce the server into attacker-chosen requests. |
| Recommendation — Treat external entity resolution as an SSRF path and remove outbound fetch capability. | ||
| OWASP ASVS | V1 — Encoding and Sanitization | XML entity handling is an input-processing issue where unsafe expansion changes the meaning of data. |
| Recommendation — Reject or neutralize XML constructs that can alter parsing behaviour through external references. | ||
Practitioner Guidance
What to verify: Confirm that XML parsers reject or ignore external entities by default in every code path, including libraries used by background jobs, importers, and test utilities. Also verify that any remaining XML handling cannot reach local files or internal HTTP endpoints from production environments.
Decision rule: If the XML comes from outside your trust boundary, disable external entity resolution and any related network fetch behaviour before you worry about schema validation or convenience features. If a workflow truly needs external references, isolate it and constrain its filesystem and network permissions first.
Common mistake: Teams often fix the obvious parser setting in one service and miss a second parser instance in another component, or they assume schema validation makes entity resolution safe. It does not. The safe choice is to remove the parser’s ability to follow attacker-chosen references unless that capability is explicitly required and tightly controlled.
Practitioner takeaway: Treat XML parsing as an execution-adjacent trust boundary, because the danger is not malformed XML, it is untrusted XML gaining the power to read, reach, and consume on your behalf.
Related resources from NHI Mgmt Group
- What breaks when SOAP services still process external entities in XML requests?
- What breaks when XML external entities are not properly blocked in spreadsheet parsers?
- What breaks when XML external entities are not disabled in Java applications?
- Why do Java XML parsers still create XXE risk even when security flags are available?