XXE is the parsing flaw that lets an attacker make the XML processor resolve external entities. SSRF is one possible result, where the server is tricked into reaching a remote URL on the attacker’s behalf. XXE can also expose local files, so SSRF is a consequence, not the same weakness.
Parsing flaw versus network side effect: how XXE and SSRF differ
XXE and SSRF are often discussed together because one can lead to the other, but they describe different layers of the problem. XXE is the XML processing weakness: the parser is allowed to resolve external entities, which gives the attacker a way to influence what the parser fetches or expands. SSRF is one possible outcome when that fetch goes to a remote resource, but XXE can also be used to read local files or interact with internal resources without fitting the classic SSRF label. The distinction matters because fixing the network symptom alone does not remove the parsing flaw, and that leaves other abuse paths open. For teams that handle XML from users, partners, or integrations, the real question is whether the parser is permitted to make untrusted resolution decisions at all. In practice, many teams discover XXE only after an unexpected outbound request or local file exposure has already happened, rather than by testing the parser’s entity-handling settings intentionally.
How XML entity abuse creates different failure paths
When XML input is processed, the parser may resolve entities before the application ever sees the final data. If external entity resolution is enabled, an attacker can point an entity reference at a URL, a local file, or another internal endpoint. The parser then performs the retrieval as part of document handling, which is why XXE can trigger both confidentiality issues and network interaction.
That is why SSRF is best understood as one effect of XXE, not a synonym for it. In an SSRF-style outcome, the important failure is that the server is induced to make a request it should never have made, often toward an internal host or protected service. In a file disclosure outcome, the same parser behaviour is used to read data that should never have been available to the requester. The root cause remains the same: unsafe XML entity processing.
- XXE describes the parser weakness.
- SSRF describes one abuse path when the parser fetches remote content.
- Local file disclosure is another abuse path when the parser resolves file references.
- Internal service reachability can turn a parsing flaw into access to metadata, admin endpoints, or trust-boundary shortcuts.
Mitigation therefore needs to focus on parser configuration, XML feature reduction, and input handling rather than only on egress filtering. If the parser still resolves entities, the application may remain exposed even when a single SSRF destination has been blocked. This guidance breaks down when XML is not actually being parsed, or when the application uses a hardened parser that disables entity resolution by default.
Where the distinction becomes operationally important
Tighter XML controls often reduce compatibility, so organisations have to balance safe parsing against legacy document handling and partner integration requirements. The practical challenge is deciding whether an observed request is evidence of SSRF abuse, broader XXE exploitation, or both. That distinction affects what evidence you preserve, what systems you inspect, and how far you trust the parser output.
When the issue is truly XXE, the response should focus on parser behaviour, entity expansion settings, DTD handling, and any place the XML library is allowed to reach out during parse time. When the issue is only described as SSRF, teams sometimes miss the underlying XML configuration problem and treat the event as a routing or proxy issue instead. Guidance is not fully uniform across vendors on the safest parser defaults, but the operational principle is consistent: untrusted XML should not be permitted to trigger arbitrary fetches or local resource access.
For teams that also manage machine identities or service-to-service trust, the intersection matters because internal endpoints are often reachable only by systems that carry elevated network trust. Even when the XML input is the entry point, the exposure may extend into identity-linked backend services, which makes the blast radius larger than a simple web request issue.
Risk and Threat Considerations
XXE is a high-value input-handling weakness because it can convert a document parser into a retrieval mechanism for internal network resources or local files. The threat is not limited to one kind of request; it depends on what the parser is allowed to resolve and what the environment trusts behind the scenes.
Failure mechanism: An attacker supplies XML that references an external entity, and the parser resolves it during document processing. If the entity points to a remote URL, the server makes an unsolicited request consistent with SSRF. If it points to local or internal resources, the parser may disclose file content or reach protected services that were never intended to be directly accessible.
Impact: The organisation can lose confidentiality through file exposure, leak internal service responses, and create an unintended bridge into private network segments. In some environments, that also becomes a pivot into privileged backend functions that assume only trusted internal callers can reach them.
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 Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1202 — Indirect Command Execution | XXE and SSRF both abuse one system to trigger actions on another. |
| T1190 — Exploit Public-Facing Application | XXE is commonly delivered through exposed application parsers accepting attacker XML. | |
| Recommendation — Map parser-triggered requests to T1202 and inspect how untrusted input induces indirect execution. Hunt for T1190-style exploitation where public XML endpoints accept attacker-controlled entities. | ||
| CIS Controls v8 | CIS 16 — Application Software Security | XXE is an input-handling flaw in application parsing logic. |
| Recommendation — Harden XML libraries under CIS 16 and disable external entity resolution by default. | ||
| NIST CSF 2.0 | PR.DS — Data Security | XXE can disclose files and internal responses, creating confidentiality exposure. |
| Recommendation — Apply PR.DS safeguards to prevent XML parsing paths from exposing sensitive data. | ||
| OWASP Non-Human Identity Top 10 | NHI-08 — Secrets and Credential Exposure | XML abuse can expose credentials, tokens, or service secrets stored in files or responses. |
| Recommendation — Use NHI-08 to remove secrets reachable through XML-parsed file and network access paths. | ||
Practitioner Guidance
What to prioritise: Treat the parser configuration as the control point, not the outbound request as the whole problem. If entity resolution is still enabled anywhere in the processing path, assume the application remains vulnerable to more than one abuse pattern.
What to verify: Confirm whether the XML stack disables external entities, DTD processing, and network retrieval during parse time. Also verify whether downstream libraries re-enable those behaviours indirectly, which is a common source of false confidence.
Decision rule: If the observed behaviour is only an outbound request, do not stop at SSRF triage. Check whether the same payload could also read local files or internal resources, because that determines whether the issue is a narrow egress control problem or a broader XML parsing weakness.
Practitioner takeaway: The most important judgment is to classify XXE as the root parsing defect and SSRF as just one possible consequence, because that is what prevents a partial fix from leaving other entity-resolution abuse paths intact.
Related resources from NHI Mgmt Group
- What is the difference between hardened XML parsing and simply sanitising XML input?
- What is the difference between application input validation and identity control?
- What is the difference between LDAP injection and ordinary input validation bugs?
- What is the difference between input sanitization and blast-radius control?