Once attacker-controlled XML is parsed as an error document, the attacker can sometimes embed local file contents or trigger remote requests through external entities. In a cloud context, that can expose filesystem data, internal network resources, or credential material reachable from the runtime. The practical consequence is a pivot from template handling into broader infrastructure exposure.
What actually happens when XML external entities are enabled in an error path?
Once the parser accepts attacker-controlled XML in an error response, the parser may process external entities before the cloud service finishes building the error document. That changes a simple validation failure into a server-side data access primitive. The exact result depends on parser settings and runtime reachability, but the risk is the same: the service can be induced to resolve attacker-chosen references.
That matters because error handlers are often assumed to be low-risk glue code. In practice, they can still invoke the full XML stack, including entity resolution, schema loading, and outbound fetches. If those behaviours are not disabled, the error path can become a reliable place to trigger file reads or internal requests without needing the main application flow.
In cloud services, the effect is often broader than one leaked file. A parser that can reach local paths may expose configuration, temporary files, or metadata artifacts. A parser that can make outbound requests may also touch internal endpoints that were never intended to be internet-facing. This is why XML parsing bugs in error handling are treated as access-path problems, not just formatting defects.
Why the blast radius can include files, metadata, and internal services
External entities let XML point at resources outside the document itself. If the parser dereferences them, the response may include local file contents, cause server-side HTTP requests, or both. In cloud-hosted workloads, those requests can interact with internal control planes, link-local services, or other private services that are only reachable from inside the runtime boundary.
The important security point is that the attacker is not “breaking XML” so much as abusing a parser feature to cross trust boundaries. The parser becomes an intermediary that can read from the host’s filesystem and speak to network locations on the attacker’s behalf. If the workload also has access to secret material, the same mechanism can expose tokens, credentials, or service configuration that should never be reflected back through an error response.
That is why the consequence is usually described as SSRF-like behaviour plus local file disclosure, even when the trigger is an error document. The error response is just the delivery vehicle. The underlying problem is uncontrolled resolution of external references during parsing, which can turn a malformed input into a reconnaissance or exfiltration channel.
Why cloud deployments make the issue worse
Cloud environments concentrate value and connectivity in the runtime. A single parser instance may sit close to instance metadata, internal APIs, shared service credentials, mounted secrets, or private service meshes. If attacker-controlled XML is allowed to reach those surfaces, the outcome is often better described as infrastructure exposure than as a narrow parser bug.
Operationally, this is also easy to miss because error handling is often exercised with untrusted input and limited test coverage. Teams may sanitize the primary request path while leaving the error renderer, XML library defaults, or auxiliary diagnostics path untouched. That makes the vulnerable code path look secondary, even though it can access the same runtime privileges as the main service.
For that reason, the right mental model is: if an error path parses XML, it is part of the attack surface. The service should be treated as exposed wherever the parser can resolve entities, load remote resources, or read local files, regardless of whether the XML came from the happy path or the failure path. See also The 52 NHI Breaches Report for how credential and secret exposure often becomes the next stage after an access-path failure, and CISA cyber threat advisories for the broader pattern of abuse paths turning into compromise chains.
Risk and Threat Considerations
The main risk is that a parse-time feature becomes a disclosure and pivot mechanism. An attacker who can influence the XML in an error document may be able to pull local content, probe internal services, or harvest metadata that helps them move deeper into the environment.
Failure mechanism: The parser resolves external entities or related references during error rendering, allowing attacker-supplied XML to trigger local file reads or server-side outbound requests.
Impact: The service can leak filesystem data, internal network reachability, or secret material, and the resulting foothold may support follow-on compromise of cloud resources.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address 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 |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | XML entity abuse can drive server-side actions and outbound requests through the parser. |
| Recommendation — Map parser-driven outbound activity and file access to ATT&CK techniques and hunt for suspicious resolution chains. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The issue arises when untrusted XML is accepted and processed unsafely in an error path. |
| SI-4 — System Monitoring | XML entity abuse often shows up as unusual file access or internal outbound requests. | |
| Recommendation — Validate error-path inputs and reject XML features that enable external entity resolution. Monitor error handlers for unexpected file reads and internal network egress. | ||
| OWASP ASVS | V1 — Encoding and Sanitization | Safe XML handling depends on strict input handling and parser-safe output processing. |
| Recommendation — Apply strict sanitization and parser-safe handling to any XML accepted in error responses. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Unsafe XML parser settings in a cloud service are a common configuration weakness. |
| Recommendation — Remove parser features that permit external entity resolution in error-processing endpoints. | ||
Practitioner Guidance
What to verify: Treat error handlers, diagnostic pages, and XML serializers as first-class inputs to security review. Verify that entity resolution, external fetching, and DTD processing are disabled wherever they are not strictly required, and confirm that the same settings apply in production builds, not just in development defaults.
What to prioritise: If any parser in an error path can reach local files or internal URLs, prioritise removal of that capability before tuning the surrounding application logic. The first question is not whether the attacker can cause a visible error, but whether the error path can touch sensitive runtime resources.
Practitioner takeaway: A malformed request is only a parser bug until the parser is allowed to dereference attacker-controlled references; once that happens, the error path becomes a potential disclosure and pivot path.
Related resources from NHI Mgmt Group
- Why does attacker-controlled XML create denial of service risk in some Node.js applications?
- What happens after an attacker can issue Kerberos service tickets on behalf of a target user?
- What happens after an attacker gains credential access in Google Cloud?
- What happens after an attacker compromises a cloud email account through brute-force or password spraying?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
