How do attackers use DTD Injection?

How DTD injection turns XML parsing into an attack path

dtd injection works because XML parsers may be willing to process a document type declaration before they parse the rest of the content. If an attacker can influence that DTD, they can change how the parser resolves entities and external references, which turns a normal parse step into a security boundary crossing. The abuse often starts in seemingly harmless XML features and ends in disclosure or outbound requests.

In practice, the attacker is not “breaking XML” so much as taking advantage of parser behaviour that was designed for flexibility. That is why this issue is often grouped with XML external entity abuse and other parser-level injection patterns. For a broader map of these web attack patterns, see NHIMG’s Web Application Attacks Guide and the OWASP Top 10.

The key technical point is that DTD processing gives the parser extra instructions before application logic sees the data. If that instruction channel is reachable from untrusted input, the attacker can use it to influence entity resolution, reference internal resources, or force the parser to fetch remote content. That makes the parser itself part of the attack surface, not just the application code that consumes the XML.

What attackers typically try to achieve

Most DTD injection payloads aim for one of three outcomes: entity expansion, local file disclosure, or server-side request forgery. Entity expansion can be used to consume resources or change how content is interpreted. Local file disclosure happens when the parser is induced to read sensitive files and return or embed the contents. SSRF happens when the parser follows attacker-controlled external references and makes network requests from the server’s environment.

Those goals are attractive because they exploit trusted parser behaviour. The attacker does not need direct shell access if they can get the XML processor to read files or reach internal services on their behalf. That is why DTD injection is frequently treated as a trust-boundary problem, not just a syntax problem. The same parsing weakness can support reconnaissance, data theft, and internal network probing.

When these behaviours occur in an application stack that already handles XML for integrations, SSO assertions, SOAP, or document exchange, the impact can be broader than the original feature set suggests. A parser that is allowed to resolve external entities in one part of the stack can become a pivot into files, metadata endpoints, or internal-only services elsewhere.

How defenders reduce the attack surface

The safest default is to disable DTD processing and external entity resolution wherever the application does not truly need them. If the parser must accept XML from untrusted sources, it should also reject unexpected DOCTYPE declarations and refuse to resolve external references by default. Those settings remove the attacker’s main leverage points and keep the parser from making network or file-system decisions on behalf of the application.

Where XML is unavoidable, validation should happen in a parser configuration that is explicitly hardened for untrusted input. Monitor the parsing paths that handle externally supplied XML, especially code paths that were added for interoperability or legacy integration. Attacks often appear first in rarely used endpoints, batch jobs, or middleware components where security assumptions lag behind functional requirements.

Attackers also look for environments where XML is transformed, proxied, or normalized before business logic runs. That is because the dangerous DTD may be introduced upstream of the code that developers normally inspect. Reviewing the full ingestion path matters more than reviewing only the final parser call.

Risk and Threat Considerations

DTD injection is high risk because it turns a parser into a privileged mediator between untrusted input and local resources. The main exposure is not the XML syntax itself, but the parser’s ability to fetch, resolve, or expand content in ways the application did not intend.

Failure mechanism: The application accepts XML with DTD processing enabled, and the parser honours attacker-controlled entity or external resource references during document parsing.

Impact: The result can be local file disclosure, SSRF into internal services, resource exhaustion from entity expansion, or a broader foothold for follow-on reconnaissance and data theft.

Practitioner Guidance

What to verify: Confirm whether every XML parser in the request path has DTDs disabled and external entity resolution blocked by default. Do not check only the primary application library, because wrappers, middleware, and transformation layers can re-enable risky behaviour.

Decision rule: If the parser must process XML from outside your trust boundary, treat DOCTYPE acceptance as a security decision, not a convenience feature. If the business case for DTDs is weak, remove them rather than trying to filter individual payloads.

What good looks like: Untrusted XML is parsed with the smallest possible feature set, unexpected DOCTYPEs are rejected early, and logs show when parsing failures are caused by prohibited document structure rather than application errors.

Practitioner takeaway: The defensive goal is to make XML parsing deterministic and boring, because any parser feature that can reach files or the network on attacker input has become an attack primitive.

Related resources from NHI Mgmt Group

• What breaks when attackers use MSBuild and APC injection inside a trusted Windows process?
• Why do attackers use shellcode and injection techniques to run code inside another process?
• What happens when attackers use thread pool based injection instead of classic remote thread techniques?
• How do attackers use shared library injection?