Heads-up rather than a bug report against JsonPath itself.
com.jayway.jsonpath:json-path:3.0.0 pulls net.minidev:json-smart:2.6.0 at runtime scope. json-smart places no
bound on the length of a single numeric literal before constructing a BigInteger / BigDecimal, and those String
constructors cost time quadratic in the digit count. So a small JSON document containing one very long number
imposes a large single-threaded CPU cost on anything that parses it.
Measured against json-smart 2.6.0 on Temurin 21.0.11 (median of 5):
| digits |
parse time |
| 100,000 |
121 ms |
| 400,000 |
1,979 ms |
| 1,600,000 |
32,432 ms |
That is ~4× per doubling — end to end n^2.02. A ~1.6 MB document with no nesting burns ~32 seconds of one core.
I've reported it upstream with a fix: netplex/json-smart-v2#301 (and netplex/json-smart-v2#300).
Why I'm flagging it here: there is currently no json-smart option a caller can set to bound this — no
maxNumberLength analogue exists in its API — so JsonPath users can't mitigate it from your side by configuration
today. Once the upstream patch lands, picking up the newer json-smart is the fix; the patch makes the bound apply
by default rather than opt-in, precisely so downstreams don't have to change anything.
Relevant if you parse attacker-supplied JSON, which is the common JsonPath use case. Nothing needed from you right
now beyond awareness — I'll follow up here if/when json-smart ships a release.
For accuracy: this is a distinct issue from the four existing json-smart CVEs (CVE-2021-27568, CVE-2021-31684,
CVE-2023-1370, CVE-2024-57699), which are recursion/depth or exception-handling problems.
— Mike Read
Heads-up rather than a bug report against JsonPath itself.
com.jayway.jsonpath:json-path:3.0.0pullsnet.minidev:json-smart:2.6.0at runtime scope. json-smart places nobound on the length of a single numeric literal before constructing a
BigInteger/BigDecimal, and those Stringconstructors cost time quadratic in the digit count. So a small JSON document containing one very long number
imposes a large single-threaded CPU cost on anything that parses it.
Measured against json-smart 2.6.0 on Temurin 21.0.11 (median of 5):
That is ~4× per doubling — end to end n^2.02. A ~1.6 MB document with no nesting burns ~32 seconds of one core.
I've reported it upstream with a fix: netplex/json-smart-v2#301 (and netplex/json-smart-v2#300).
Why I'm flagging it here: there is currently no json-smart option a caller can set to bound this — no
maxNumberLengthanalogue exists in its API — so JsonPath users can't mitigate it from your side by configurationtoday. Once the upstream patch lands, picking up the newer json-smart is the fix; the patch makes the bound apply
by default rather than opt-in, precisely so downstreams don't have to change anything.
Relevant if you parse attacker-supplied JSON, which is the common JsonPath use case. Nothing needed from you right
now beyond awareness — I'll follow up here if/when json-smart ships a release.
For accuracy: this is a distinct issue from the four existing json-smart CVEs (CVE-2021-27568, CVE-2021-31684,
CVE-2023-1370, CVE-2024-57699), which are recursion/depth or exception-handling problems.
— Mike Read