XInclude Injection

How XInclude injection works

XInclude injection abuses XML inclusion processing, not just parsing. When an application accepts attacker-controlled XML and leaves XInclude enabled, the parser may resolve references to files, internal services, or other local resources during document expansion. That turns a formatting feature into a data-access primitive.

The key issue is that inclusion happens inside the parser, often before the application has a chance to validate what is being loaded. A payload can therefore cause the processor to fetch content that the application never intended to expose, especially when it assumes XML is only being read, not dereferenced.

Why it is dangerous

The danger comes from trust crossing boundaries. XInclude can let an attacker reach resources that sit behind network controls, read local files that should never be exposed, or splice unexpected content into a document flow. In practice, that can become file disclosure, SSRF-like retrieval, or integrity loss in downstream XML processing.

This is especially serious when XML is used for configuration, document exchange, or backend integration, because the resulting content may be consumed by privileged components. Even if the original input looks harmless, the parser may still perform retrieval as part of normal inclusion handling.

XXE Guide is the most useful internal companion here because XInclude injection sits in the same parser-hardening problem space as XXE and other XML inclusion weaknesses.

Where to check exposure

Exposure depends on whether any XML parser, library, middleware layer, or document pipeline allows XInclude resolution. Organisations should look for XML handling in APIs, import jobs, document converters, SSO and metadata flows, and any service that processes externally supplied XML on behalf of another system.

Useful checks include code review of parser settings, runtime inspection of parser behaviour, and review of vendor or framework defaults. The practical question is simple: can attacker-controlled XML cause the processor to dereference local paths or internal URLs?

OWASP Top 10 is a reasonable external baseline for application teams reviewing parser-driven injection risk, even though the exact issue is a lower-level XML weakness.

How to reduce impact and detect abuse

Reduce exposure by disabling XInclude processing unless the application explicitly needs it, and by using XML parser settings that prevent external retrieval behaviour. Where XML must be accepted, treat inclusion features as attack surface, not convenience defaults.

Detection should focus on unexpected parser fetches, unusual file reads, and outbound requests triggered during XML handling. If exploitation is suspected, review recent XML inputs, parser logs, and any local or internal resources that may have been referenced during expansion.

After a suspected event, review whether the parser may have disclosed sensitive files, configuration data, or internal service content. If secrets, credentials, certificates, or tokens were exposed through included data, rotate them and assess downstream trust relationships that may have been affected.

Risk and Threat Considerations

XInclude injection is risky because it turns parser behaviour into an access path. A seemingly simple XML document can become a mechanism for reading sensitive local content or reaching internal network targets if inclusion is permitted and the application does not tightly control what XML processors may resolve.

Failure mechanism: The parser expands attacker-supplied XInclude references during normal document processing, so the application inherits whatever file and network reach the parser has at runtime.

Impact: Attackers may disclose files, retrieve internal resources, alter downstream document content, or use the parser as a stepping stone to broader internal reconnaissance.

Practitioner Guidance

What to watch for: Treat XInclude as a parser feature that must be explicitly justified. If your stack handles untrusted XML, verify that inclusion is disabled by default or tightly constrained, and confirm that testing covers document types that can trigger XML expansion paths.

Practitioner note: The safest assumption is that any XML feature capable of fetching or merging external content can become an exposure point when input is attacker-controlled. Hardening parser defaults is usually more effective than trying to sanitise inclusion payloads after the fact.

Related resources from NHI Mgmt Group

• What is credential injection risk and how does it occur?
• What is the difference between prompt injection risk and identity abuse in agents?
• What is the difference between prompt injection and credential theft for agents
• What is the difference between prompt injection and tool poisoning?