CVE-2023-1370 is a denial-of-service vulnerability in the json-smart Java library where parsing deeply nested JSON arrays or objects exhausts the call stack and crashes the application. Rated 7.5 (High), CVE-2023-1370 is dangerous mainly because json-smart is rarely a dependency you added on purpose; it rides in transitively under widely used libraries, so a lot of teams are exposed without knowing json-smart is even on the classpath.
The root cause: no depth limit on recursion
json-smart parses JSON by recursing. When the parser hits a [ character it descends to parse an array; when it hits a { it descends to parse an object. The bug is that older versions impose no limit on how deep this nesting can go. Every level of nesting consumes another frame of stack memory. Feed the parser a payload with thousands of opening brackets and the Java Virtual Machine's stack space runs out, throwing a StackOverflowError that kills the parsing thread and can take down the whole application.
Because the payload is trivial to generate and requires no authentication, an unauthenticated remote attacker can crash any endpoint that parses attacker-supplied JSON with a vulnerable json-smart:
Conceptual malicious payload (deeply nested, truncated):
[[[[[[[[[[ ... thousands of levels ... ]]]]]]]]]]
You do not need a working exploit script to understand the risk: any request body, webhook, or token that eventually reaches json-smart parsing is a candidate.
Affected versions and the fix
json-smart versions before 2.4.9 are affected. The vulnerability was fixed in 2.4.9, but the maintainer recommends upgrading to 2.4.10 because a remaining bug was addressed there. So the practical remediation is: get to 2.4.10 or later.
<!-- Pin json-smart explicitly to override a vulnerable transitive version -->
<dependency>
<groupId>net.minidev</groupId>
<artifactId>json-smart</artifactId>
<version>2.4.10</version>
</dependency>
Why this one is easy to miss
Very few projects declare json-smart directly. It commonly arrives underneath authentication and JWT libraries and other JSON-handling frameworks. That means a grep of your own source for "json-smart" turns up nothing while a vulnerable copy sits three levels down in your dependency tree.
Maven makes the actual tree visible:
mvn dependency:tree -Dincludes=net.minidev:json-smart
For Gradle:
./gradlew dependencyInsight --dependency json-smart
If either command shows a version below 2.4.10, you are affected even though you never chose to use the library. This transitive-hiding behavior is precisely the gap that a software composition analysis tool closes: it reads the resolved dependency graph, not just your top-level manifest, so an SCA tool such as Safeguard can flag CVE-2023-1370 transitively even when json-smart never appears in your pom.xml.
Remediation without breaking parents
The wrinkle with transitive fixes is that a parent library may pin an old json-smart. Forcing an upgrade can occasionally break the parent if it relied on removed behavior, though for this fix the API surface is stable. Two clean approaches:
- Dependency management override. In Maven, add json-smart 2.4.10 to
<dependencyManagement>so every transitive reference resolves to the safe version. In Gradle, use a resolution strategy or constraint. - Upgrade the parent. If the library that pulls in json-smart has released a version that already depends on 2.4.10 or later, upgrading the parent is the cleanest path because it keeps the dependency contract intact.
After either change, re-run the dependency-tree command to confirm the vulnerable version is genuinely gone from the resolved graph, not merely present alongside the new one.
Defense in depth for JSON parsing
Even after patching, treat untrusted JSON parsing defensively. Cap request body sizes at the edge so a giant nested payload is rejected before it reaches the parser. Where your framework allows it, configure a maximum nesting depth. These controls limit the damage from any future recursion bug in any JSON library, not just this one. Resource-exhaustion denial of service is a recurring category, and input-size limits are cheap insurance.
FAQ
What does CVE-2023-1370 do?
It lets an unauthenticated attacker crash a Java application that parses untrusted JSON with json-smart by sending deeply nested arrays or objects, exhausting the stack and triggering a StackOverflowError. It is a denial-of-service issue, not remote code execution.
Which json-smart version fixes CVE-2023-1370?
The fix landed in 2.4.9, but the maintainer recommends 2.4.10 or later because a further bug was resolved there. Upgrade to at least 2.4.10.
I do not use json-smart directly, am I still at risk?
Very possibly. json-smart is usually pulled in transitively by other libraries. Run mvn dependency:tree -Dincludes=net.minidev:json-smart (or the Gradle equivalent) to check the resolved version.
What is the CVSS severity of CVE-2023-1370?
7.5, High. The high rating reflects that it is remotely triggerable without authentication or user interaction, even though the impact is limited to availability.