CVE-2026-59171: 
Java vulnerability analysis and mitigation

CVE-2026-59171 is an uncontrolled resource consumption (DoS) vulnerability in JSON-java (org.json), the widely used reference implementation of a JSON package in Java. JSONTokener.nextSimpleValue() accumulates numeric characters into an unbounded StringBuilder, which is then passed to JSONObject.stringToNumber() where new BigInteger(val) or new BigDecimal(val) is called without any length guard — both constructors have super-linear (O(n^1.585)) time complexity due to Karatsuba multiplication. The vulnerability affects all versions from 20150729 through 20260522; version 20260719 introduces a numeric conversion length limit. It carries a CVSS v3.1 base score of 5.9 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). In JSONTokener.java (lines 500–504), the nextSimpleValue() method appends characters to a StringBuilder with no length cap until a structural JSON character is encountered; the resulting string is then forwarded to JSONObject.stringToNumber() (lines 2721–2748), which directly invokes new BigInteger(val) or new BigDecimal(val) without any size guard. A secondary attack vector exists via short exponent-notation literals (e.g., 1e100000000, only 11 characters) that bypass the parse-time length check because they are stored compactly as BigDecimal but expand to hundreds of millions of digits when getBigInteger()/optBigInteger() calls BigDecimal.toBigInteger(). Critically, neither withStrictMode(true) nor withKeepStrings(true) in JSONParserConfiguration prevents the vulnerable code path, and all three primary entry points — new JSONObject(String), new JSONArray(String), and XML.toJSONObject(String) — are equally affected (GitHub Advisory, PR #1065, PR #1067).

Successful exploitation causes a denial-of-service condition by blocking Java request-handling threads for extended periods — a single 488 KB JSON body containing a 500,000-digit numeric literal blocks one Tomcat thread for approximately 3 seconds, and a 1 MB payload (within nginx's default body-size limit) can block a thread for nearly 12 seconds. An attacker sending 200 concurrent such requests (~95 MB total) can exhaust a default 200-thread Tomcat pool, causing legitimate requests to queue and time out. There is no confidentiality or integrity impact; the vulnerability is purely an availability risk affecting any Java web application that passes attacker-controlled JSON or XML input to org.json parsing APIs (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the time of this report. The EPSS score is approximately 0.0055 (0.55%), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Attack complexity is rated High because exploitation requires the target application to explicitly use org.json (rather than the default Jackson library in Spring Boot) and to pass user-controlled input directly to a JSON/XML parsing API — conditions beyond the attacker's direct control (Feedly, GitHub Advisory).

1. Reconnaissance: Identify target Java web applications that use org.json (Maven artifact org.json:json) for JSON or XML parsing, rather than the default Jackson library. This can be inferred from dependency manifests, error messages, or behavioral fingerprinting.
2. Identify vulnerable endpoint: Locate an HTTP endpoint that accepts a JSON or XML request body and passes it to new JSONObject(requestBody), new JSONArray(requestBody), or XML.toJSONObject(requestBody) without pre-validation.
3. Craft the payload: Construct a JSON body containing a very long unquoted numeric literal, e.g., {"amount":999...999} with 500,000 nines (~488 KB total), which is within nginx's default 1 MB body-size limit.
4. Send concurrent requests: Use a load-generation tool (e.g., ab, wrk, or hey) to send 200 or more concurrent POST requests with the crafted payload to the target endpoint.
5. Achieve thread-pool exhaustion: Each request occupies one server thread for ~3 seconds during BigInteger construction; with enough concurrent requests, the thread pool is exhausted and the server stops responding to legitimate traffic.
6. Alternative — exponent notation bypass: For applications running a partially patched version, send a short exponent-notation literal such as {"x":1e100000000} (11 characters, bypassing parse-time length guards) and trigger getBigInteger() on the parsed value to cause OOM or thread stall (GitHub Advisory, PR #1067).

• Network: Repeated HTTP POST requests to JSON-consuming endpoints with Content-Length values in the range of 100 KB–1 MB and Content-Type: application/json; high concurrency of such requests from one or few source IPs.
• Logs: Web server access logs showing many simultaneous long-duration requests (>1–3 seconds) to the same endpoint; application logs showing thread-pool saturation or request queue timeouts (e.g., Tomcat maxThreads exhaustion warnings).
• Process/JVM: Sustained high CPU usage on the Java process during request handling without corresponding network I/O; JVM thread dumps showing many threads blocked inside java.math.BigInteger.<init> or java.math.BigDecimal.<init> called from org.json.JSONObject.stringToNumber.
• Application: Sudden increase in HTTP 503 or 504 responses from the application; health-check endpoints becoming unresponsive while the JVM process remains alive.

Primary remediation: Upgrade org.json (Maven: org.json:json) to version 20260719 or later, which introduces a hard limit of 1,000 characters on numeric token length in stringToValue() for both JSONObject and XML, and adds bounds checking in objectToBigInteger() to prevent the exponent-notation bypass (GitHub Release, PR #1065, PR #1067).

Defense-in-depth workarounds (not substitutes for patching):

• Configure an upstream reverse proxy body-size limit (e.g., nginx: client_max_body_size 64k;) to reduce the maximum achievable digit count.
• For Spring Boot applications, register a servlet filter that rejects requests with Content-Length exceeding a safe threshold before the body reaches the controller.
• If using the patched version, optionally configure JSONParserConfiguration.withMaxNumberLength(n) to set a custom limit, or pass UNDEFINED_MAXIMUM_NUMBER_LENGTH to disable the guard for trusted inputs.

The vulnerability was reported by researcher waydeshi and disclosed via GitHub Security Advisories on August 1, 2026. The maintainer (stleary) acknowledged the issue promptly, reviewed and merged the fix within days, and released version 20260719 on July 19, 2026. The advisory explicitly contextualizes the issue relative to prior CVEs in the same library (CVE-2022-45688, CVE-2023-5072) and draws a comparison to Jackson 2.15's StreamReadConstraints.withMaxNumberLength() fix, which addressed the same vulnerability class in 2023 without a CVE assignment. The Apereo CAS project was among the first downstream consumers observed updating their dependency in response (GitHub Advisory, PR #1065).