CVE-2022-40152: Woodstox XML Parsing Denial of Service

CVE-2022-40152 is a denial-of-service vulnerability in the Woodstox XML parser: an attacker who can supply XML with deeply nested constructs can drive the parser into unbounded recursion and trigger a stack overflow that crashes the application. It was fixed in Woodstox 6.4.0 (and in the 5.x line at 5.4.0), and it matters broadly because Woodstox is a default XML backend for a lot of Java software, including XStream and many JAXB-based stacks — so plenty of teams ship it without ever naming it.

The flaw is not exotic. It is the classic "parser trusts nesting depth" problem, and it is a good case study in why XML input from untrusted sources needs hard limits.

Root cause: recursion with no depth ceiling

Woodstox parses XML, and when DTD (Document Type Definition) processing is involved, deeply nested structures are handled recursively. The vulnerability is that the parser did not adequately cap how deep that recursion could go. Feed it a document with thousands of nested elements or nested DTD content and each level pushes another frame onto the call stack until the JVM runs out of stack space and throws a StackOverflowError, taking down the thread — and often the request-handling capacity of the service.

This sits in the same family as the "billion laughs" entity-expansion attack, but the mechanism here is stack depth from nesting rather than memory blow-up from entity expansion. Both share a root cause: an XML parser accepting attacker-controlled structure without bounding it.

Any service that parses XML received from an untrusted source — a SOAP endpoint, a webhook consumer, a file-upload feature, an API that accepts XML bodies — is a candidate for exposure if it runs a vulnerable Woodstox underneath.

Affected and fixed versions

Woodstox is affected in the following ranges:

• 6.x: versions before 6.4.0
• 5.x: versions before 5.4.0

The fix in 6.4.0 added configurable limits for maximum nesting depth (including for DTD subsets), so the parser rejects over-deep documents instead of recursing into a crash. XStream releases up to and including 1.4.19 shipped a vulnerable Woodstox and are commonly cited alongside this CVE because XStream depends on it.

Find your resolved version — it is usually transitive:

# Maven
mvn dependency:tree -Dincludes=com.fasterxml.woodstox:woodstox-core

# Gradle
./gradlew dependencyInsight --dependency woodstox-core

The fix

Upgrade woodstox-core to 6.4.0 or later (or 5.4.0+ if you are pinned to the 5.x line for compatibility reasons):

<dependency>
  <groupId>com.fasterxml.woodstox</groupId>
  <artifactId>woodstox-core</artifactId>
  <version>6.4.0</version>
</dependency>

If Woodstox arrives through XStream or another library, prefer upgrading that library to a release that depends on a patched Woodstox. Forcing a Woodstox override under an old XStream can work, but test it — XML backends and their consumers are sensitive to version skew.

Harden your XML parsing regardless

A version bump fixes this CVE, but XML parsing deserves defensive configuration as a standing practice, because new parser DoS issues appear regularly:

1. Disable DTD processing when you do not need it. Most modern XML payloads do not require DTDs, and turning them off removes an entire attack surface — this also mitigates XXE. Set supportDTD to false on your input factory.
2. Set explicit limits. On patched Woodstox, configure maximum nesting depth, maximum element count, and maximum attribute size to values matched to your legitimate traffic.
3. Reject oversized payloads early. Cap request body size at the edge so a multi-megabyte nested document never reaches the parser.
4. Prefer JSON where you control both ends — it sidesteps the entire DTD/entity class of attacks.

// Defensive: disable DTDs on the input factory
XMLInputFactory f = XMLInputFactory.newFactory();
f.setProperty(XMLInputFactory.SUPPORT_DTD, false);
f.setProperty("javax.xml.stream.isSupportingExternalEntities", false);

Why manual tracking misses this

CVE-2022-40152 is a transitive dependency in almost every project that has it. You add XStream, or a SOAP client, or a Spring module that handles XML, and Woodstox comes along for the ride — invisible in your top-level build file. A manual review of declared dependencies will not surface it.

Software composition analysis solves exactly this. An SCA tool resolves the whole tree, pins the actual Woodstox version, and matches it against the vulnerable range even when it is three libraries deep. A platform such as Safeguard can additionally track which of your services still resolve a vulnerable Woodstox after a partial rollout, so you close the gap everywhere rather than in the one repo you remembered. Our dependency scanner guide explains how that resolution and matching works.

FAQ

What kind of vulnerability is CVE-2022-40152?

It is a denial-of-service (availability) issue. Malicious XML with deep nesting causes a stack overflow that crashes the parsing thread. There is no code execution or data disclosure — the risk is that an attacker can knock a service over with a single crafted document.

Do I need DTDs enabled to be vulnerable?

The DTD processing path is the primary trigger for the deep-recursion behavior in this CVE. Disabling DTD support (supportDTD=false) is both a strong mitigation and good practice generally, since most applications do not need DTDs and disabling them also closes XXE vectors.

Is XStream affected by CVE-2022-40152?

XStream versions up to and including 1.4.19 bundle a vulnerable Woodstox, so they are commonly listed against this CVE. Upgrading XStream to a release that depends on patched Woodstox (6.4.0+) resolves it; you can also override the Woodstox version directly if needed.

How do I know which version of Woodstox my app uses?

Run mvn dependency:tree -Dincludes=com.fasterxml.woodstox:woodstox-core for Maven or the equivalent dependencyInsight command for Gradle. Because Woodstox is nearly always a transitive dependency, checking your build file alone will not tell you — you have to resolve the full tree.