CVE-2022-45688 is a stack-overflow denial-of-service vulnerability in the XML-to-JSON conversion component of the Hutool Java toolkit, triggered by deeply nested input that exhausts the call stack during recursive parsing. It carries a CVSS score of 7.5 (High) and affects hutool-json 5.8.10, with the same root cause present in the closely related org.json:json package before release 20230227. If your service accepts XML or JSON from untrusted clients and converts between the two formats, this is worth understanding.
The bug is not an exotic memory-corruption issue. It is a plain resource-exhaustion flaw, which makes it easy to trigger and easy to remediate.
What the vulnerable code does
Hutool is a broad Java utility library, and hutool-json includes an XML.toJSONObject method that parses an XML document into a JSON structure. The parser is recursive: each nested XML element causes another recursive call as the parser descends into the document tree.
There is no depth limit on that recursion. When an attacker submits a document with thousands of nested tags, the parser keeps calling itself until the JVM thread's stack space runs out. At that point the JVM throws StackOverflowError, the request-handling thread dies, and depending on how the application is structured, this can cascade into unavailability.
The published advisory for CVE-2022-45688 describes exactly this: a crafted payload causing a stack overflow leading to denial of service.
A conceptual look at the trigger
You do not need a working exploit to understand the shape of the problem. Imagine an XML body that looks like this, repeated to a large depth:
<a><a><a><a><a> ... </a></a></a></a></a>
Each <a> opens another level. A document that is only a few hundred kilobytes on the wire can encode tens of thousands of nesting levels, which is far more than the default JVM stack can absorb. The JSON side has the same weakness with deeply nested objects or arrays.
The reason this matters for org.json too is that Hutool's implementation and the reference org.json library share the same recursive-descent design for this conversion. Both were addressed around the same time.
Affected versions and the fix
Based on the advisory data:
- hutool-json: version 5.8.10 is affected. Upgrade to 5.8.11 or later.
- org.json:json: versions before 20230227 are affected. Upgrade to 20230227 or later.
The upgrade is a straightforward dependency bump. In Maven:
<dependency>
<groupId>cn.hutool</groupId>
<artifactId>hutool-json</artifactId>
<version>5.8.11</version>
</dependency>
Or with the aggregate hutool-all artifact, move to a release that pulls in a fixed hutool-json. For org.json:
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>20230227</version>
</dependency>
Because org.json is an extremely common transitive dependency, you may be shipping a vulnerable copy without ever declaring it directly. Running mvn dependency:tree and grepping for org.json or hutool is the fastest way to find every path that resolves to it:
mvn dependency:tree | grep -E "org.json|hutool"
Mitigations when you cannot upgrade immediately
Sometimes an upgrade is blocked by a downstream compatibility test cycle. In that window, reduce exposure rather than leaving the endpoint open:
Cap request body size. A stack-overflow-by-nesting attack needs enough depth to exhaust the stack, and depth correlates with document size. A tight body-size limit at the reverse proxy or framework layer raises the bar considerably.
Validate structure before parsing. If you control the input contract, reject documents whose nesting exceeds a sane bound before handing them to the converter. For XML specifically, a SAX pre-pass counting open-element depth is cheap.
Isolate the parsing thread. If conversion runs on a dedicated worker pool with a bounded queue, a StackOverflowError on one worker does not take down request threads serving the rest of the application.
None of these are substitutes for the upgrade. They buy time.
Why denial-of-service bugs deserve attention
Teams sometimes deprioritize DoS findings because they do not leak data. That reasoning is incomplete. Availability is one of the three properties in the classic security triad, and a single crafted request that can knock over a request thread is cheap for an attacker to send repeatedly. For an API that sits in a payment path or an authentication flow, an outage is a direct business cost.
The broader lesson is that any recursive parser handling untrusted input needs an explicit depth guard. This same pattern, unbounded recursion over attacker-controlled nesting, recurs across XML, JSON, YAML, and protobuf libraries in every language. Catching it early is exactly the kind of thing continuous dependency scanning is built for. If you want to see how a finding like this surfaces across a repository, the SCA product overview shows the workflow, and our academy covers dependency risk triage in more depth.
FAQ
What is the CVSS score of CVE-2022-45688?
It is rated 7.5, High severity. The vector reflects a network-exploitable, low-complexity attack that requires no privileges or user interaction and impacts availability only. There is no confidentiality or integrity impact.
Which packages are affected by CVE-2022-45688?
hutool-json version 5.8.10, and the org.json:json package before release 20230227. Both share the recursive XML-to-JSON parsing design that the crafted-nesting payload exploits.
How do I fix CVE-2022-45688?
Upgrade hutool-json to 5.8.11 or later, and upgrade org.json:json to 20230227 or later. Because org.json is frequently pulled in transitively, check your full dependency tree rather than only your direct dependencies.
Is CVE-2022-45688 remotely exploitable?
Yes, if your application exposes an endpoint that converts client-supplied XML or JSON using the affected components. The attacker sends a deeply nested document that exhausts the parsing thread's stack. If you never feed untrusted input to XML.toJSONObject or the equivalent JSON path, the practical risk is much lower, though upgrading remains the right call.