CVE-2026-18401: 
Java vulnerability analysis and mitigation

CVE-2026-18401 is a Denial of Service vulnerability in the non-blocking (asynchronous) JSON parser of FasterXML jackson-core, caused by failure to enforce the maxNumberLength constraint defined in StreamReadConstraints. An unauthenticated attacker who can submit JSON to an application using the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion. The vulnerability affects com.fasterxml.jackson.core:jackson-core versions 2.15.0–2.18.5 and 2.19.0–2.21.0, as well as tools.jackson.core:jackson-core versions 3.0.0–3.0.x; versions prior to 2.15.0 are unaffected because StreamReadConstraints did not exist before that release. It carries a CVSS v4.0 base score of 6.9 (Medium) per NVD, though the upstream FasterXML security advisory (GHSA-72hv-8253-57qq) rates it 8.7 (High) (GitHub Advisory, FasterXML Advisory).

The root cause (CWE-770: Allocation of Resources Without Limits or Throttling) lies in the async parsing path within NonBlockingUtf8JsonParserBase and related classes, which never invoke the number length validation methods. Specifically, number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. Unlike the synchronous parser, _valueComplete() in the async path does not call resetInt() or resetFloat() — the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed — so maxNumberLength is never enforced. The fix, contributed by @pjfanning in PR #1555, introduces private helper methods _setIntLength(), _setFractLength(), and _setExpLength() that call the appropriate StreamReadConstraints validation before assigning the length fields (FasterXML PR #1555, Fix Commit). A public PoC JUnit test demonstrating the bypass is included in the upstream advisory (FasterXML Advisory).

Successful exploitation results in a Denial of Service affecting availability only — there is no confidentiality or integrity impact. An attacker can cause unbounded memory allocation in the TextBuffer, triggering an OutOfMemoryError and crashing or destabilizing the JVM process. If the application subsequently calls getBigIntegerValue() or getDecimalValue() on the oversized token, the JVM may additionally be consumed by O(n²) BigInteger parsing operations, causing CPU-based exhaustion. Applications most at risk are reactive/non-blocking services such as Spring WebFlux or other frameworks that use the async parser API (FasterXML Advisory, GitHub Advisory).

A public proof-of-concept JUnit test is included in the upstream FasterXML security advisory (GHSA-72hv-8253-57qq), demonstrating that the async parser silently accepts a 5,000-digit number that the synchronous parser correctly rejects. The NVD SSVC assessment classifies exploitation as "poc" and the vulnerability as "automatable." No in-the-wild exploitation has been reported, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.31% (24th percentile), indicating low near-term exploitation probability (FasterXML Advisory, GitHub Advisory).

1. Identify target: Locate an application that accepts JSON input and uses the jackson-core async (non-blocking) parser API — common in Spring WebFlux, Vert.x, or other reactive frameworks running jackson-core 2.15.0–2.18.5 or 2.19.0–2.21.0.
2. Craft malicious payload: Construct a JSON document containing a number field with a value exceeding 1,000 digits (the default maxNumberLength). For example: {"v":111111...} where the integer is 5,000+ digits long.
3. Submit payload: Send the crafted JSON to any HTTP endpoint that processes it with the async parser (e.g., a POST request with Content-Type: application/json).
4. Trigger memory exhaustion: The async parser accumulates all digits into the TextBuffer without enforcing the length constraint, causing unbounded heap allocation.
5. Optionally trigger CPU exhaustion: If the application calls getBigIntegerValue() or getDecimalValue() on the parsed token, the JVM enters O(n²) BigInteger parsing, consuming CPU and potentially causing a full service outage (FasterXML Advisory, FasterXML PR #1555).

• Network: Repeated HTTP POST requests with unusually large JSON bodies (kilobytes to megabytes) containing a single numeric field with thousands of digits; anomalous request sizes to JSON-consuming API endpoints.
• Logs: Application logs showing java.lang.OutOfMemoryError or java.lang.OutOfMemoryError: Java heap space originating from jackson-core async parser classes (e.g., NonBlockingUtf8JsonParserBase); JVM GC logs showing sudden heap exhaustion.
• Process: JVM process exhibiting sudden spike in heap memory usage followed by crash or restart; high CPU utilization in threads performing BigInteger operations after JSON parsing.
• Application: Service unavailability or repeated restarts of reactive/non-blocking application instances (Spring WebFlux, Vert.x, etc.) correlating with inbound JSON requests (FasterXML Advisory).

Upgrade com.fasterxml.jackson.core:jackson-core to version 2.18.6 or 2.21.1 (for the 2.x line), or to 3.1.0 (for the 3.x line), which enforce maxNumberLength in the async parser path. If an immediate upgrade is not feasible, consider switching affected endpoints to use the synchronous parser API, which correctly enforces the constraint. As an additional defense-in-depth measure, configure StreamReadConstraints with a reduced maxNumberLength value and apply request body size limits at the API gateway or load balancer layer to restrict oversized payloads. IBM has issued a security bulletin for affected products (IBM Sterling Control Center, IBM Enterprise Build with Quarkus) and recommends applying the patched jackson-core version (FasterXML Advisory, IBM Advisory).

The FasterXML maintainers initially did not consider this CVE-worthy, with @pjfanning noting that the effect of multi-thousand-digit numbers involves non-linear CPU time in the Java Runtime itself, and that if Jackson has an issue, so does the Java Runtime. Red Hat Product Security reached out to assign a CVE, but the maintainers declined at the time; a CVE was ultimately assigned later. The fix was nonetheless merged promptly (PR #1555, February 22, 2026). Downstream projects including Confluent Kafka, JetBrains Kotlin, Apache Iceberg, and others have since updated their jackson-core dependencies to address GHSA-72hv-8253-57qq (FasterXML PR #1555).