json-smart 2.6.0 dependency has an unbounded numeric-literal parse cost (quadratic CPU)

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