What is XML Bomb (Billion Laughs Attack)? Ways to Exploit, Examples and Impact

In the world of cybersecurity, some of the most devastating attacks don't involve complex malware or social engineering. Instead, they leverage the very logic of the protocols we use to exchange data. One such classic yet still relevant threat is the XML Bomb, most famously known as the "Billion Laughs" attack. This type of Denial of Service (DoS) attack targets XML parsers by exploiting the way they handle Document Type Definitions (DTD) and entity expansion. By sending a tiny, seemingly innocent XML file, an attacker can force a server to consume gigabytes of memory and 100% of its CPU resources, effectively knocking it offline.

To understand how this works, we must first dive into the technical foundations of XML and how it processes internal data structures. As organizations continue to rely on XML for legacy systems, SOAP APIs, and configuration files, understanding the mechanics of an XML Bomb is essential for any security professional or developer. This guide will walk you through the technical details, provide concrete examples, and outline how to defend your infrastructure using tools like Jsmon.

What is an XML Bomb?

An XML Bomb is a type of resource exhaustion attack. It is not designed to steal data or gain unauthorized access; rather, its sole purpose is to make a system unavailable. The attack relies on the "Entity Expansion" feature of XML. In XML, you can define entities in the Document Type Definition (DTD) section. These entities act like variables or macros. When the XML parser encounters an entity reference, it replaces the reference with the defined value.

The "Billion Laughs" attack is a specific recursive version of an XML bomb. It is called "Billion Laughs" because the original example used the string "lol" as the entity value. By nesting these entities, an attacker can create an exponential growth pattern. A file smaller than 1 KB can expand into several gigabytes of data once processed in the server's memory.

How the Billion Laughs Attack Works

To understand the mechanics, we need to look at how DTDs handle internal entities. A standard XML entity looks like this:

<!ENTITY myentity "This is a string">

When the parser sees &myentity; in the XML body, it replaces it with "This is a string". The XML Bomb takes this concept and applies recursion (or more accurately, nested references).

The Billion Laughs Payload Example

Here is the classic structure of a Billion Laughs attack:

<?xml version="1.0"?>
<!DOCTYPE lolbomb [
 <!ENTITY lol "lol">
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolbomb>&lol9;</lolbomb>

Let’s break down the math behind this:

1. lol contains the string "lol" (3 bytes).
2. lol1 contains 10 lol entities (30 bytes).
3. lol2 contains 10 lol1 entities (300 bytes).
4. ...and so on.

By the time the parser reaches lol9, it is attempting to expand the original "lol" string 1,000,000,000 (one billion) times. If the string "lol" is 3 bytes, the final expansion requires 3 gigabytes of RAM. If an attacker adds just one more level (lol10), the requirement jumps to 30 gigabytes. Most web servers will exhaust their available memory and crash long before they finish processing this expansion.

XML Bomb vs. XML External Entity (XXE)

It is common to confuse XML Bombs with XML External Entity (XXE) attacks, as both involve DTDs. However, their goals and methods differ:

• XML Bomb (Billion Laughs): Focuses on Availability. It uses internal entities to cause resource exhaustion (DoS). It does not require the parser to access external resources.
• XXE (XML External Entity): Focuses on Confidentiality and Integrity. It uses external entities to fetch local files (like /etc/passwd), perform Server-Side Request Forgery (SSRF), or scan internal ports. It requires the parser to be configured to fetch external URIs.

While an attacker might use Jsmon to find endpoints that accept XML, the vulnerability they look for depends on the parser's configuration. A parser that disables external entities might still be vulnerable to internal entity expansion (XML Bomb) unless specifically hardened.

Ways to Exploit XML Bomb Vulnerabilities

Exploitation is straightforward because it relies on the default behavior of many older or misconfigured XML libraries. Attackers look for any entry point where a user can provide XML input.

1. SOAP-based Web Services

SOAP (Simple Object Access Protocol) is entirely XML-based. Many enterprise systems still use SOAP for internal and external communication. If the SOAP processor does not have limits on entity expansion, an attacker can wrap a Billion Laughs payload inside a SOAP envelope.

2. REST APIs with XML Support

Many modern REST APIs are configured to accept both JSON and XML. Even if the primary documentation suggests JSON, the underlying framework (like Spring in Java or Express with certain body-parsers) might automatically parse XML if the Content-Type: application/xml header is sent. An attacker can test this by sending a simple XML snippet and seeing if the server processes it.

3. File Uploads

Applications that allow users to upload files that are later parsed as XML—such as SVG images, Office documents (.docx, .xlsx), or configuration files—are prime targets. An SVG file is just an XML document. An attacker can embed a Billion Laughs payload inside an SVG file, and when the server attempts to generate a thumbnail or process the image, it crashes.

The Quadratic Blowup Attack: A Variation

If a parser has protection against deep recursion (nested entities), an attacker might try a "Quadratic Blowup" attack. Instead of nesting entities, the attacker defines one very large entity and repeats it thousands of times in the document body.

<!DOCTYPE bomb [
 <!ENTITY a "aaaaaaaaaa... (repeated 50,000 times)">
]>
<bomb>&a;&a;&a;&a;&a;... (repeated 50,000 times)</bomb>

In this case, the expansion is not exponential, but it is quadratic. If the entity &a; is 50 KB and it is called 50,000 times, the resulting expansion is 2.5 GB. This often bypasses simple recursion depth checks while still achieving the same DoS result.

Impact of XML Bomb Attacks

The primary impact is Denial of Service (DoS). However, the consequences can be more nuanced:

• System Crashes: The immediate exhaustion of RAM causes the specific process or the entire operating system to crash.
• Service Degradation: Even if the server doesn't crash, the 100% CPU usage will make the application unresponsive for all other users.
• Financial Loss: For e-commerce or critical infrastructure, downtime directly translates to lost revenue and damaged reputation.
• Masking Other Attacks: A DoS attack can be used as a distraction. While security teams are busy trying to bring the server back online, an attacker might execute a more subtle attack elsewhere in the infrastructure.

How to Detect XML Bomb Vulnerabilities

Detection can be handled through manual testing and automated scanning. When testing manually, security researchers often use "mini-bombs"—payloads that expand to a few megabytes—to observe if the response time increases significantly without actually crashing the production environment.

Automated tools are more efficient for large-scale environments. Using Jsmon allows you to map out your attack surface and identify every endpoint that might be accepting XML. Once identified, these endpoints can be audited for proper parser configuration.

Prevention and Mitigation Strategies

Defending against XML bombs is primarily a matter of secure coding and proper configuration of XML libraries. The most effective defense is to disable DTDs entirely if they are not needed.

1. Disable DTDs Completely

Most modern applications do not need DTDs. By disabling them, you eliminate the risk of both XML bombs and XXE.

In Python (defusedxml):
The standard xml library in Python is vulnerable. Use the defusedxml library instead.

from defusedxml.ElementTree import parse
# This is safe against Billion Laughs

In Java (JAXP):
You must explicitly set the attributes to disable DTDs and limit expansion.

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

2. Limit Entity Expansion

If your application requires DTDs for some reason, you must set strict limits on the number of entities that can be expanded and the total size of the expanded data. Most enterprise-grade parsers (like Xerces) provide settings to limit the "Entity Expansion Limit."

3. Use Modern Parsers

Many modern XML libraries have built-in protections. For example, libxml2 (used in PHP, Ruby, and others) includes protections against excessive entity expansion by default in newer versions. However, developers should always verify that these protections are active.

4. Web Application Firewalls (WAF)

A WAF can be configured to inspect incoming XML payloads for common patterns like the Billion Laughs structure. While a WAF shouldn't be your only line of defense, it provides an important layer of virtual patching.

Conclusion

The XML Bomb, or Billion Laughs attack, remains a potent threat because it exploits fundamental features of the XML standard. Despite being an older vulnerability, the continued use of XML in enterprise environments and the default configurations of many libraries keep it relevant today. By understanding the mechanics of recursive entity expansion and implementing secure parsing practices—such as disabling DTDs and setting expansion limits—developers can effectively neutralize this threat.

Proactive monitoring is the first step in securing your environment. To proactively monitor your organization's external attack surface and catch exposures before attackers do, try Jsmon.