CWE-776 Base Draft Medium likelihood

Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')

This vulnerability occurs when an XML parser allows Document Type Definitions (DTDs) to contain recursively defined entities without proper limits, enabling malicious data structures.

Definition

What is CWE-776?

This vulnerability occurs when an XML parser allows Document Type Definitions (DTDs) to contain recursively defined entities without proper limits, enabling malicious data structures.
Attackers can craft a malicious DTD that defines XML entities in a recursive loop—where one entity references another, which then references back to the first, creating a chain. When the parser expands these entities, what looks like a small XML file in memory explodes into a massive data structure, consuming excessive CPU and memory. This results in a classic Denial-of-Service (DoS) attack, often called 'XML Entity Expansion' or 'Billion Laughs.' To prevent it, developers should disable DTD processing entirely in their XML parsers when possible, or explicitly configure them to restrict entity expansion depth and total memory usage during parsing.
Real-world impact

Real-world CVEs caused by CWE-776

How attackers exploit it

Step-by-step attacker path

  1. 1

    Identify a code path that handles untrusted input without validation.

  2. 2

    Craft a payload that exercises the unsafe behavior — injection, traversal, overflow, or logic abuse.

  3. 3

    Deliver the payload through a normal request and observe the application's reaction.

  4. 4

    Iterate until the response leaks data, executes attacker code, or escalates privileges.

Vulnerable code example

Vulnerable XML

The DTD and the very brief XML below illustrate what is meant by an XML bomb. The ZERO entity contains one character, the letter A. The choice of entity name ZERO is being used to indicate length equivalent to that exponent on two, that is, the length of ZERO is 2^0. Similarly, ONE refers to ZERO twice, therefore the XML parser will expand ONE to a length of 2, or 2^1. Ultimately, we reach entity THIRTYTWO, which will expand to 2^32 characters in length, or 4 GB, probably consuming far more data than expected.

Vulnerable XML
<?xml version="1.0"?>
  <!DOCTYPE MaliciousDTD [
  <!ENTITY ZERO "A">
  <!ENTITY ONE "&ZERO;&ZERO;">
  <!ENTITY TWO "&ONE;&ONE;">
  ...
  <!ENTITY THIRTYTWO "&THIRTYONE;&THIRTYONE;">
  ]>
  <data>&THIRTYTWO;</data>
Attacker payload

The DTD and the very brief XML below illustrate what is meant by an XML bomb. The ZERO entity contains one character, the letter A. The choice of entity name ZERO is being used to indicate length equivalent to that exponent on two, that is, the length of ZERO is 2^0. Similarly, ONE refers to ZERO twice, therefore the XML parser will expand ONE to a length of 2, or 2^1. Ultimately, we reach entity THIRTYTWO, which will expand to 2^32 characters in length, or 4 GB, probably consuming far more data than expected.

Attacker payload XML
<?xml version="1.0"?>
  <!DOCTYPE MaliciousDTD [
  <!ENTITY ZERO "A">
  <!ENTITY ONE "&ZERO;&ZERO;">
  <!ENTITY TWO "&ONE;&ONE;">
  ...
  <!ENTITY THIRTYTWO "&THIRTYONE;&THIRTYONE;">
  ]>
  <data>&THIRTYTWO;</data>
Secure code example

Secure pseudo

Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist

How to prevent CWE-776

  • Operation If possible, prohibit the use of DTDs or use an XML parser that limits the expansion of recursive DTD entities.
  • Implementation Before parsing XML files with associated DTDs, scan for recursive entity declarations and do not continue parsing potentially explosive content.
Detection signals

How to detect CWE-776

Automated Static Analysis High

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

CWE-776

Don't catalog this weakness. Prove it's reachable.

Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.

Frequently asked questions

Frequently asked questions

What is CWE-776?

This vulnerability occurs when an XML parser allows Document Type Definitions (DTDs) to contain recursively defined entities without proper limits, enabling malicious data structures.

How serious is CWE-776?

MITRE rates the likelihood of exploit as Medium — exploitation is realistic but typically requires specific conditions.

What languages or platforms are affected by CWE-776?

MITRE lists the following affected platforms: XML.

How can I prevent CWE-776?

If possible, prohibit the use of DTDs or use an XML parser that limits the expansion of recursive DTD entities. Before parsing XML files with associated DTDs, scan for recursive entity declarations and do not continue parsing potentially explosive content.

How does Plexicus detect and fix CWE-776?

Plexicus's SAST engine matches the data-flow signature for CWE-776 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.

Where can I learn more about CWE-776?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/776.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)