XXE attacks show why XML parsers need tighter security controls

At a glance

What this is: Probely argues that XXE attacks exploit weak XML parser configuration to turn ordinary document processing into file disclosure, SSRF, denial of service, or code execution.

Why it matters: For IAM, NHI, and application security teams, XXE is a reminder that parser hardening, input validation, and downstream network controls have to be governed as one control surface.

Context

XML remains widely used for service integration, configuration, and data interchange, which is why parser security still matters. The security problem is not the format itself but the way parsers are allowed to resolve external entities from untrusted input, creating a path from document parsing to filesystem access and network abuse.

XXE is a classic application security issue, but it has governance value beyond web apps because parser settings often sit at the boundary between development, runtime configuration, and network exposure. When that boundary is unmanaged, the parser becomes an unreviewed trust decision embedded in code and infrastructure rather than a controlled security setting.

Key questions

Q: What breaks when XML parsers still resolve external entities?

A: 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.

Q: Why does XXE sometimes lead to SSRF or denial of service?

A: XXE can trigger SSRF when the parser is allowed to fetch internal or external resources on the attacker’s behalf. It can also cause denial of service when entity expansion or repeated fetches exhaust CPU, memory, or network capacity. The risk emerges because the parser inherits the application’s network reach and processing power.

Q: How should security teams prevent XXE in XML-heavy applications?

A: Start by disabling external entity resolution and DTD processing in every parser, then verify those settings in code, libraries, and middleware. Add allowlists only where business requirements demand external references, and pair that with restricted file and network privileges so a parser failure cannot expose internal systems or sensitive data.

Q: What should teams do when they discover XXE in production code?

A: Contain the vulnerable service, disable external entity processing, and validate whether the parser has already reached files or internal endpoints. Then patch the code, test for SSRF and resource exhaustion, and review service privileges so the same flaw cannot reappear with broader impact.

Technical breakdown

How XXE abuses external entity resolution

XML parsers can be configured to expand external entities so documents can reference content outside the original file. That feature becomes dangerous when the parser accepts untrusted XML and resolves those references without restriction. An attacker can craft a document that points to local files, internal endpoints, or other resources the application should never disclose. The parser then acts as the delivery mechanism for data extraction or internal request generation. This is why XXE is not just malformed input handling. It is a trust failure in how the parser interprets references and where it is allowed to reach.

Practical implication: disable external entity resolution by default and treat any exception as a formally approved parser exception.

Why XXE becomes SSRF, denial of service, or code execution

Once a parser is allowed to fetch external resources, the impact can extend beyond file reads. If the parser can reach internal services, XXE can trigger server-side request forgery and bypass network intent boundaries. If it is fed resource-intensive entity references, it can consume CPU, memory, or outbound request capacity and create denial of service. In poorly governed stacks, parser misuse can also become a stepping stone toward arbitrary code execution when the vulnerable component is coupled with unsafe processing paths. The common thread is that XML parsing is no longer a local function. It becomes an execution path with network and runtime consequences.

Practical implication: map parser behavior to both application and network controls, not just to input validation checks.

Secure XML processing depends on parser, code, and runtime controls

A hardened XML parser is only one layer. Teams also need allowlists for any external references that remain necessary, safe input validation, regular dependency updates, and monitoring that can detect unexpected entity resolution attempts. Where XML is not required, simpler formats such as JSON reduce the attack surface by removing entity and DTD handling altogether. In practice, XXE prevention is a configuration and governance problem as much as a coding issue. It is most effective when parser settings, secure coding standards, and deployment controls are aligned instead of being managed by separate teams with different assumptions.

Practical implication: standardise secure XML settings in build and runtime baselines and prohibit parser drift between environments.

Threat narrative

Attacker objective: The attacker wants to turn XML parsing into a route for data exposure, internal request abuse, or server compromise.

1. Entry occurs when an application accepts attacker-controlled XML and passes it to a parser that still resolves external entities.
2. Credentialed or privileged access is not required because the parser itself becomes the trusted intermediary for reading local files or reaching internal services.
3. Escalation follows when the attacker uses entity references to pivot into SSRF, resource exhaustion, or unsafe downstream behaviour that affects the wider environment.
4. Impact is disclosure of sensitive files, disruption of service, or in extreme cases remote code execution on the affected server.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

XXE is a parser governance problem, not just an input validation bug. The technical failure begins when XML parsers are allowed to resolve external entities from untrusted content without an explicit governance decision. That means the real control gap sits across application code, parser configuration, and runtime policy. Practitioners should treat parser behaviour as a security policy surface, not a developer convenience.

External entity resolution creates a trust boundary that most teams do not monitor. The article shows how a harmless-looking document can force server-side requests or file reads once the parser is misconfigured. That is a classic example of hidden trust in a low-level library becoming an attack path. Security teams should make parser settings inventoryable, reviewable, and enforceable through baseline controls.

SSRF is the identity-adjacent risk hidden inside XXE. The security problem is not only exposure of content but also unauthorized use of the server’s network reach. In identity and access terms, the parser is effectively borrowing the application’s trust to act on internal resources. That makes network segmentation, egress control, and least-privilege service design part of XXE governance, not separate concerns.

XML complexity creates control debt when teams keep parser features they do not need. The cleanest risk reduction is often to remove unnecessary XML processing, especially where JSON would satisfy the use case. Where XML must remain, organisations need named ownership for parser settings, dependency refresh, and incident response for parser abuse. The practical conclusion is simple: complexity that is not governed becomes attack surface.

Secure XML processing should be managed like any other privileged execution path. If an application can read files, reach internal services, or exhaust resources through parser behaviour, then parser configuration deserves the same discipline as privileged access. That is why XXE belongs in secure design reviews, runtime hardening, and application security verification, not only in code review.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Top 10 Agentic AI Identity Issues

What this signals

Parser hardening only works when teams govern the full trust path. XXE shows how a low-level library setting can become an enterprise risk once it is connected to internal services and sensitive files. For practitioners, the control question is not whether XML is used, but whether any parser in the environment can resolve attacker-supplied references without review.

XML complexity is the real governance debt. The more a platform relies on entity expansion, DTD handling, and outbound reference resolution, the more attack surface it creates for application and network teams. That is why secure design baselines should prefer simpler data formats where possible and make parser exceptions visible where XML remains necessary.

For practitioners

• Disable external entity resolution by default Set XML parsers to reject external entities and DTD processing unless a documented business case exists and the exception is explicitly approved.
• Allowlist only trusted XML references If XML must resolve external content, restrict references to trusted sources and verify that each allowlisted endpoint is necessary for the application.
• Harden parser settings in build and runtime baselines Bake secure XML parser configuration into shared libraries, deployment templates, and environment baselines so settings do not drift between teams.
• Scan code paths that parse XML Use automated security testing and code review to flag XML parsing logic that accepts untrusted input, especially in services that bridge internal networks.
• Monitor for anomalous entity resolution and SSRF patterns Alert on unexpected outbound requests, internal service calls, or parser errors that indicate XXE probing or successful exploitation attempts.

Key takeaways

• XXE turns XML parsing into a security boundary problem when external entities are still allowed in untrusted workflows.
• The main risks are file disclosure, SSRF, denial of service, and in severe cases code execution.
• The most effective control is to disable external entity processing by default and govern every exception explicitly.

Key terms

• XML External Entities (XXE): An XXE attack abuses XML parser behaviour so external references are resolved from untrusted input. The attacker can sometimes read files, trigger internal requests, or force resource exhaustion, depending on how the parser and the surrounding service are configured.
• External Entity Resolution: External entity resolution is the parser feature that follows references to content outside the XML document. It is useful in legitimate workflows, but in untrusted contexts it widens the trust boundary and can expose files, internal endpoints, or sensitive backend data.
• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• XML Parser Hardening: XML parser hardening is the practice of configuring parsing libraries so untrusted XML cannot resolve external entities or trigger uncontrolled expansion. In practice, that means using safe defaults, limiting document complexity, and testing parser behavior against malicious inputs. The goal is to preserve availability and prevent unintended data access.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.