XML External Entity injection, commonly abbreviated as XXE, is a security vulnerability that occurs when an application processes untrusted XML using an improperly configured parser.
A vulnerable XML parser may accept instructions that tell it to load data from an external resource. An attacker can manipulate those instructions to make the application read sensitive local files, contact internal services, send information to an external server, or consume excessive system resources.
XXE is a server-side vulnerability. The dangerous activity normally occurs inside the application, document processor, API, or background service that parses the malicious XML.
Possible consequences include:
- Sensitive-file disclosure
- Server-Side Request Forgery
- Internal-network scanning
- Credential theft
- Data exfiltration
- Denial of service
- Exposure of application source code
- Access to cloud services
- Compromise of connected systems
The vulnerability is strongly associated with Document Type Definitions, external entities, and XML parsers that allow external resource resolution.
What Is XML?
Extensible Markup Language, or XML, is a structured data format used to store and exchange information.
XML has been used in:
- Web services
- SOAP APIs
- Document formats
- Configuration files
- Identity systems
- Enterprise integrations
- Data imports and exports
- Mobile application backends
- Office documents
- Image formats such as SVG
- RSS feeds
- SAML authentication
- Payment systems
- Government and healthcare platforms
An XML document contains elements, attributes, and values organized into a hierarchical structure.
Although many modern APIs use JSON, XML remains important in enterprise applications, older platforms, document processors, and industry-specific systems.
What Is an XML Entity?
An XML entity is a named value that an XML parser can substitute when processing a document.
Some entities represent simple internal text. Others can reference content located outside the XML document.
An external entity may point to:
- A local file
- A remote web resource
- A network service
- Another XML document
- A system resource
External entities can be useful in controlled environments, but they become dangerous when an untrusted user can define or influence them.
If the parser automatically retrieves the specified resource, the attacker may turn the application into an intermediary that accesses information on their behalf.
How Does an XXE Attack Work?
A typical XXE attack follows this pattern:
- An application accepts or receives XML.
- The XML contains a document type declaration or another external reference.
- The attacker defines an entity that points to an unintended resource.
- The parser allows external entity processing.
- The application retrieves the referenced file or network location.
- The parser places the retrieved information into the processed document or uses it internally.
- The attacker receives the data or observes another effect.
The application may not be designed to access files or contact internal systems through that feature. The parser performs the action because external resource resolution is enabled.
OWASP explains that XXE can expose local files, trigger server-side requests, scan internal systems, and cause denial of service. Its central recommendation is to disable DTDs and external entity processing whenever they are unnecessary. OWASP’s XXE Prevention Cheat Sheet provides parser-specific guidance.
Why Is XXE Dangerous?
XML parsing often takes place inside trusted server environments.
The parser may have access to:
- Application configuration
- Environment variables
- Private network services
- Cloud metadata
- Customer records
- Internal APIs
- Authentication services
- Local files
- Shared network storage
- Administrative tools
- Service credentials
An attacker who controls external entity references may abuse the parser’s network position and filesystem permissions.
The attack can bypass boundaries that prevent ordinary internet users from reaching these resources directly.
Common Types of XXE Attacks
File-Disclosure XXE
An attacker defines an external entity that refers to a local file accessible to the application.
If the application returns the entity’s resolved content, the attacker may read:
- Configuration files
- Source code
- Environment data
- System information
- Application secrets
- Cloud credentials
- User records
- Private keys
Whether a particular file can be retrieved depends on the application’s permissions and how the parser handles its contents.
MITRE classifies inadequate restriction of XML external entity references as CWE-611. The weakness may allow attackers to read local files when the parser resolves an attacker-controlled external reference. MITRE’s CWE-611 entry documents the vulnerability.
XXE-Based SSRF
An external entity may point to a network address instead of a local file.
The parser then makes a request from the vulnerable server. This creates a form of Server-Side Request Forgery, or SSRF.
An attacker may attempt to reach:
- Internal APIs
- Administrative interfaces
- Monitoring services
- Cloud metadata endpoints
- Private web applications
- Development tools
- Container-management services
- Services bound to the local host
- Network devices
The server may be permitted to access locations blocked from the public internet.
In-Band XXE
With in-band XXE, the application returns the resolved information directly in its response.
For example, information retrieved from a local file may appear in an error message, API response, document preview, or generated webpage.
Because the attacker receives immediate feedback, in-band vulnerabilities may be easier to identify and exploit.
Blind XXE
Blind XXE occurs when the application processes the external entity but does not return its value to the attacker.
The attacker may still detect the vulnerability through:
- An external callback
- DNS activity
- HTTP requests
- Differences in response time
- Parser errors
- Internal service effects
- Monitoring alerts
Blind XXE can still expose sensitive information if the parser can be made to send data to an attacker-controlled system.
Out-of-Band XXE
In an out-of-band XXE attack, the vulnerable server communicates with an external system through a separate channel.
The main application response may look normal, while the parser sends a DNS or network request elsewhere.
Restricting application-server egress can prevent or limit this communication.
Error-Based XXE
Some parsers include sensitive information in error messages.
An attacker may deliberately trigger an XML processing failure that causes file contents or internal resource details to appear inside a verbose error response.
Secure error handling should prevent parser diagnostics from being displayed to users.
Parameter Entity XXE
XML supports different types of entities. Parameter entities are used inside a document type definition rather than in the main document content.
Some parser configurations block ordinary external entities but continue to allow parameter entities or external DTD retrieval.
Preventing XXE therefore requires comprehensive parser configuration rather than disabling only one feature.
External DTD-Based XXE
A document may reference an external Document Type Definition, or DTD.
If the parser retrieves that DTD from an untrusted location, the external document can introduce additional entity definitions and processing instructions.
Applications that do not need DTDs should disable them entirely.
XML Entity Expansion Attack
An XML document can define entities that repeatedly reference other entities.
When expanded recursively, a small input may grow into a huge amount of data, consuming memory and processor time.
This denial-of-service technique is often known as an XML bomb or Billion Laughs attack.
The weakness is related to XXE but may use internal entity expansion rather than an external resource. MITRE tracks improper restriction of recursive entity references as CWE-776. MITRE’s CWE-776 entry explains how nested entities can cause resource exhaustion.
XInclude Injection
XInclude is an XML mechanism that can combine information from multiple documents.
Some applications parse XML securely at first but later perform XInclude processing. If user-controlled content reaches that stage, it may introduce another path for loading local or remote resources.
Developers must evaluate every XML transformation and processing stage, not only the initial parser.
XXE Through File Uploads
An application may accept a file that contains XML internally even if the visible file extension is not .xml.
Potential examples include:
- Office documents
- SVG images
- E-book formats
- Application packages
- Design files
- Configuration archives
- XML-based media formats
If a backend service extracts and parses embedded XML, a malicious upload may trigger XXE.
Second-Order XXE
Second-order XXE occurs when malicious XML is stored before it is parsed.
For example, the application may accept a document and save it without immediate processing. A reporting service, indexing system, or administrator tool later parses the stored document using an unsafe configuration.
The delay between submission and execution can make detection more difficult.
Where Do XXE Vulnerabilities Appear?
XXE may exist anywhere untrusted or partially trusted XML is processed.
Common locations include:
- SOAP web services
- XML APIs
- SAML authentication systems
- Document converters
- Office-file processors
- SVG image handlers
- RSS and feed readers
- Data-import tools
- Payment integrations
- Enterprise middleware
- Healthcare systems
- Government applications
- Mobile backends
- Configuration importers
- E-commerce integrations
- PDF generators
- Reporting systems
- Cloud-management tools
- Message queues
- Background processing jobs
The user interface may not mention XML. An API framework can silently convert submitted data into XML, or a file parser may process XML embedded inside a larger archive.
What Causes XXE?
The root cause is processing attacker-influenced XML with parser features that permit unsafe external resource resolution.
Common causes include:
- DTD processing enabled unnecessarily
- External general entities enabled
- External parameter entities enabled
- Automatic external DTD loading
- XInclude processing enabled
- An outdated XML parser
- Unsafe default parser settings
- Inconsistent settings across services
- Parsing untrusted document formats
- Relying only on input filtering
- Excessive filesystem permissions
- Unrestricted outbound network access
- Detailed parser errors
- Failure to test background processors
- Assuming internal XML is trustworthy
Security configuration must be applied to every parser instance, including parsers created indirectly by frameworks and third-party libraries.
What Is the Difference Between XXE and XML Injection?
XML injection is a broad category in which attacker-controlled input changes the structure or meaning of an XML document.
XXE specifically abuses XML entities or external resource-loading features.
XML injection might alter an element, attribute, query, or business transaction without using external entities. XXE relies on unsafe parser behavior involving entities, DTDs, or related resource-resolution mechanisms.
What Is the Difference Between XXE and SSRF?
SSRF makes a server send an unintended network request.
XXE is a parser vulnerability that can cause file access, network requests, entity expansion, or other effects.
When an XXE payload directs the parser to a network destination, XXE becomes the method used to produce SSRF.
Not all XXE attacks involve network requests, and not all SSRF vulnerabilities involve XML.
What Is the Difference Between XXE and File Inclusion?
Both vulnerabilities can expose local files.
File inclusion manipulates a filename or resource loaded by application code. XXE manipulates external references interpreted by an XML parser.
File inclusion may also cause code execution when the selected file is interpreted as program code. XXE commonly causes disclosure or server-side requests, although it can contribute to more serious compromise when combined with other weaknesses.
What Is the Difference Between XXE and XPath Injection?
XPath injection manipulates a query used to select information from XML data.
XXE manipulates how the XML parser resolves entities and external resources.
XPath injection is comparable to SQL injection in that it changes a query. XXE occurs earlier, while XML is being parsed or transformed.
Warning Signs of an XXE Attack
Developers and security teams may observe:
- XML containing unexpected document type declarations
- External entity declarations
- Requests referencing local files
- XML parsers contacting unfamiliar domains
- Unexpected DNS lookups from application servers
- Requests to internal addresses
- Connections to unusual ports
- Attempts to reach cloud metadata services
- XML parsing errors containing filesystem paths
- Responses containing configuration data
- Large memory or CPU consumption during XML processing
- Slow or unresponsive parser services
- Repeated malformed XML documents
- Uploaded documents causing network activity
- Background jobs accessing unrelated files
- XML processors reading sensitive directories
- Unusual application-server egress
- Parser failures immediately after document uploads
A single parsing error does not confirm exploitation. Monitoring should correlate incoming XML, application activity, DNS records, outbound connections, file access, and resource consumption.
How Can Developers Prevent XXE?
Disable DTD Processing
The safest general defense is to disable Document Type Definitions when the application does not require them.
OWASP recommends disabling DTDs completely because this also prevents many external entity and recursive expansion attacks. OWASP’s prevention guidance includes configuration examples for common languages and parsers.
The exact setting varies by:
- Programming language
- XML parser
- Framework
- Parser version
- Processing API
Developers should consult the official documentation for the exact version in use.
Disable External General Entities
If DTDs cannot be disabled, configure the parser so external general entities are not resolved.
This blocks many attempts to retrieve local files or remote resources through ordinary entity references.
Disable External Parameter Entities
External parameter entities must also be disabled.
Blocking only general entities may leave alternative DTD-processing paths available. Every external entity mechanism should be reviewed.
Disable External DTD Loading
The parser should not automatically retrieve an external DTD from a URL or filesystem location supplied by the document.
If an application requires a known DTD, use a controlled local catalog or trusted mapping rather than permitting arbitrary resource resolution.
Disable XInclude
Turn off XInclude processing unless the application explicitly requires it.
If XInclude is necessary, limit the permitted resources and ensure that untrusted input cannot control the include location.
Use a Secure Parser Configuration
Do not assume the parser is safe by default.
Security settings can change across versions, platforms, frameworks, and processing functions. The same application may use different XML libraries in:
- API endpoints
- File uploads
- Background workers
- Reporting services
- Authentication components
- Third-party integrations
Create a centralized, tested method for producing securely configured parsers.
Keep XML Libraries Updated
Older XML parsers and document-processing libraries may contain vulnerabilities or unsafe defaults.
Maintain an inventory of XML-related dependencies and apply security updates promptly.
Updates should cover indirect dependencies as well as libraries imported directly by the application.
Prefer Simpler Data Formats Where Appropriate
When the business function does not require XML-specific capabilities, a simpler format such as JSON may reduce the attack surface.
Changing formats does not automatically make an application secure. The replacement parser still requires input validation, size limits, safe deserialization, and secure error handling.
Validate XML Structure
Validate incoming XML against a strict schema when practical.
Schema validation can enforce:
- Expected elements
- Permitted attributes
- Data types
- Value lengths
- Document structure
- Allowed namespaces
Schema validation is valuable, but it does not replace disabling dangerous parser features. The parser may resolve external entities before validation occurs.
Limit Document Size and Complexity
Apply limits to:
- Total document size
- Element depth
- Attribute count
- Entity expansion
- Processing time
- Memory use
- Number of nodes
- Transformation complexity
- Uploaded archive size
These controls reduce denial-of-service risk from oversized, deeply nested, or computationally expensive XML.
Restrict Outbound Network Access
An XML parser usually does not need unrestricted access to the internet or internal network.
Use:
- Egress firewalls
- Network policies
- Security groups
- Proxy allowlists
- Service meshes
- Container restrictions
Allow only the destinations required by the application.
This limits XXE-based SSRF and out-of-band data exfiltration even if a parser is misconfigured.
Apply Least Privilege
The parsing service should run with minimal filesystem and network permissions.
It should not be able to read:
- Application secrets
- Private keys
- Other customers’ files
- Cloud credentials
- Deployment configuration
- Administrative data
- Unrelated system directories
Document converters and upload processors are good candidates for separate low-privilege service accounts.
Isolate Document Processing
High-risk XML and document processing can run in a dedicated, restricted environment with:
- Minimal filesystem access
- No unnecessary network connectivity
- A read-only system image
- Temporary storage
- CPU and memory limits
- Processing timeouts
- Limited credentials
- Container or sandbox controls
Isolation provides another layer when a parser or document library fails.
Use a Safe Entity Resolver
When an application must support specific external references, use a custom resolver that maps approved identifiers to trusted local resources.
Reject every reference not explicitly allowed.
Avoid resolvers that attempt to identify dangerous locations through substring checks alone.
Protect Error Messages
Do not return raw parser errors to users.
Detailed errors may reveal:
- Local filesystem paths
- Internal network locations
- Parser versions
- File contents
- Application structure
- Processing behavior
Send detailed diagnostic information only to protected logs.
Review All XML-Based File Formats
Security testing should include files that contain XML internally.
Do not assume a document is safe because its visible extension is not .xml. Inspect how each uploaded format is unpacked, parsed, transformed, rendered, and indexed.
Why Input Filtering Alone Is Not Enough
Attempting to remove entity declarations or suspicious text from raw XML is unreliable.
XML supports:
- Namespaces
- Encodings
- External subsets
- Parameter entities
- Multiple parsing stages
- Nested documents
- Transformations
- XInclude
- Embedded XML formats
A filter may interpret the document differently from the actual parser.
The correct defense is to configure the parser so unsafe behavior is unavailable, then combine that configuration with validation, resource limits, isolation, and network controls.
Can a Web Application Firewall Stop XXE?
A web application firewall, or WAF, may detect obvious external entity declarations or known malicious XML patterns.
However, a WAF may not see:
- Encrypted document content
- Compressed XML
- XML embedded in uploaded archives
- Stored documents parsed later
- Internal service-to-service messages
- Alternative encodings
- Parser-specific syntax
- Background-processing traffic
A WAF can add detection and temporary containment, but secure parser configuration remains essential.
How Should XXE Be Tested?
XXE testing must be performed only with explicit authorization.
A security review should identify:
- Every XML parser
- SOAP endpoints
- SAML processing
- XML APIs
- Uploaded XML-based documents
- File conversion services
- Feed readers
- Background workers
- Third-party integrations
- Transformation pipelines
- Template and reporting systems
Reviewers should determine whether:
- DTDs are allowed
- External entities are resolved
- External DTDs are retrieved
- XInclude is enabled
- The parser can access local files
- The service can reach internal networks
- Outbound internet access is available
- Entity expansion is limited
- Parser errors expose sensitive information
- The service runs with excessive privileges
Testing should use controlled callback infrastructure and harmless test resources. It should not retrieve real secrets, scan unauthorized systems, or disrupt production services.
How Can Organizations Detect XXE?
Useful monitoring sources include:
- Application logs
- XML parser errors
- DNS query records
- Proxy logs
- Network-flow logs
- Firewall events
- File-access auditing
- Cloud metadata access
- Endpoint detection
- Container runtime alerts
- Upload-processing logs
- CPU and memory metrics
High-value alerts include:
- A document-processing service contacting an unfamiliar domain
- An XML parser accessing sensitive files
- Requests to internal-only addresses
- Unexpected cloud metadata traffic
- Resource exhaustion during XML parsing
- External DTD retrieval from an unapproved source
- Raw filesystem information appearing in responses
What Should an Organization Do After Detecting XXE?
Disable the Affected Parser or Endpoint
Temporarily disable the vulnerable XML-processing function or restrict it to trusted users.
If possible, switch to a securely configured parser while the full investigation and remediation continue.
Block External Resource Resolution
Disable DTDs, external entities, external DTD retrieval, and XInclude as appropriate.
Apply outbound network restrictions to the affected service.
Preserve Evidence
Collect:
- Submitted XML documents
- Application requests
- Parser errors
- DNS queries
- Outbound connections
- File-access logs
- Cloud audit activity
- Authentication records
- Background-job records
- System resource metrics
Follow the organization’s incident-response and evidence-handling procedures.
Determine What the Parser Accessed
Investigators should establish:
- Which local files were requested
- Which network destinations were contacted
- Whether internal services were reached
- Whether cloud metadata was accessed
- What information was returned
- Whether data was sent externally
- Whether the attack caused service disruption
- Whether credentials were exposed
- Whether other vulnerabilities were targeted
Rotate Exposed Credentials
If the parser could read configuration files, secrets, cloud metadata, or application credentials, rotate potentially affected:
- Database passwords
- API tokens
- Cloud credentials
- Signing keys
- Encryption secrets
- Service-account credentials
- Administrative passwords
- Deployment keys
Review how the old credentials were used.
Correct Every Parser Configuration
Fixing one endpoint may leave other vulnerable processing paths.
Review all application services, libraries, background jobs, authentication components, converters, and integration systems that process XML.
Create automated tests that fail if unsafe parser options are enabled.
Monitor After Recovery
Continue monitoring for:
- Repeated malicious XML submissions
- Requests to internal resources
- Metadata service access
- Reuse of exposed credentials
- Unusual DNS activity
- Unexpected outbound connections
- Resource-exhaustion attempts
- Related attacks against other parsers
Can XXE Lead to Remote Code Execution?
XXE usually provides file access, SSRF, data exfiltration, or denial of service rather than direct code execution.
However, it may contribute to remote code execution when:
- An internal service reached through SSRF has a dangerous vulnerability
- Exposed credentials provide administrative access
- Retrieved configuration reveals another attack path
- A parser or supporting library has an additional exploitable flaw
- The attacker can alter a file later executed by the system
The final impact depends on the environment and the vulnerabilities available in connected components.
Does HTTPS Prevent XXE?
No.
HTTPS protects XML while it travels between systems. It does not control how the receiving application parses the document.
Malicious XML can be sent through a fully encrypted HTTPS connection and still exploit an unsafe parser.
Is XXE Still Relevant in Modern Applications?
Yes.
Many current parsers use safer defaults, but XXE remains relevant because:
- Legacy systems still process XML
- Enterprise integrations rely on SOAP
- SAML uses XML
- Document formats contain embedded XML
- Applications may override secure defaults
- Older libraries remain deployed
- Different services use different parser configurations
- Background processors are often overlooked
A modern frontend using JSON does not prove that its document, identity, reporting, or integration services are free from XML processing.
Can XXE Affect Cloud Applications?
Yes.
A vulnerable cloud workload may use XXE to access:
- Cloud metadata services
- Mounted secrets
- Workload identity credentials
- Internal APIs
- Private storage
- Container services
- Deployment systems
- Management interfaces
Cloud applications should combine secure parser settings with least-privilege workload identities, metadata protections, network segmentation, and egress filtering.
Is XXE Only a Web Application Vulnerability?
No.
Any software that processes attacker-influenced XML may be affected, including:
- Desktop applications
- Mobile backends
- Enterprise middleware
- Document converters
- Command-line tools
- File-indexing services
- Email gateways
- Security scanners
- Build pipelines
- Embedded devices
The underlying issue is unsafe XML parsing, not the presence of a browser.
