XML Entity Expansion (Billion Laughs)

Also known as the "billion laughs" attack, this is a denial-of-service variant that lives inside the broader XXE family: instead of defining an external entity that fetches a file or URL, the attacker defines a chain of internal entities where each one references the previous one multiple times. A handful of nested definitions, each expanding into ten copies of the one before it, produces an exponential blowup: ten levels deep is already ten billion copies of a short string, enough to exhaust memory on a parser that expands entities without any limit. The XML itself, as submitted, is tiny, often just a few hundred bytes, which is what makes this attack disproportionately dangerous relative to its size.

• XML-accepting endpoints

• Submit billion-laughs payload to XML parsing endpoint

• <!ENTITY a 'lol'><!ENTITY b '&a;&a;&a;...'>... (billion laughs)

This one needs to stay advisory rather than attack-and-confirm: actually running a full billion-laughs payload against a production target would cause the exact denial-of-service the test is trying to identify. A safer approach is testing with a shallow, tightly bounded nesting depth (enough to prove entities are being expanded without any limit) rather than the full exponential payload, and treating any successful shallow expansion as sufficient evidence without ever scaling up to a depth that would actually exhaust memory.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

Active billion-laughs would DoS the target - never run.

Manual Testing Methodology

Here is a systematic approach to identifying XML Entity Expansion (Billion Laughs) vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For XML Entity Expansion (Billion Laughs) specifically, submit a minimal DOCTYPE declaration defining an external entity pointing at a local file (<!ENTITY xxe SYSTEM "file:///etc/passwd">) referenced from a text node in the document body, then retry with an out-of-band variant (an entity pointing at a collaborator URL) to catch blind cases where the response doesn't echo the entity value directly.

Compare the response against your baseline, looking specifically for file contents appearing in the parsed response, an out-of-band DNS/HTTP callback on the collaborator domain, or a distinctive parser error confirming DTD processing occurred even without data exfiltration.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For XML Entity Expansion (Billion Laughs), a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

XML external entity injection lets attackers interfere with how an application parses XML. By defining external entities that reference local files, internal network resources, or out-of-band channels, an attacker can read arbitrary files from the server, perform SSRF against internal services, trigger denial-of-service through entity expansion, and in some cases achieve remote code execution.

XXE is dangerous largely because default XML parser configurations in many languages process external entities unless a developer explicitly disables that behavior. That means any application accepting XML input, whether through a SOAP API, SVG upload, or document processing, is potentially exposed without anyone realizing it.

In cloud environments, XXE often provides a direct path to SSRF against the metadata endpoint, which makes it a particularly high-value finding when file read access can be demonstrated.

Prevention and Secure Coding

Preventing XML Entity Expansion (Billion Laughs) takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Disable external entity resolution. Explicitly disable DTD processing and external entity resolution in the XML parser configuration — this is the single control that matters; everything else is secondary hardening.

Check every parser in the pipeline, not just the obvious one. SVG upload handlers, PDF generators, and office-document parsers all typically parse XML internally and inherit the same default-insecure behavior as a direct XML API endpoint.

Prefer a data format that doesn't need this control at all. Where XML isn't a hard requirement, JSON removes this entire vulnerability class by construction.

Keep parser libraries current. Some historic CVEs in XML libraries bypassed the standard "disable external entities" flag; patch level matters here as much as configuration.