EOL Fix Available | CVE-2026-18401

Overview

jackson-core is the core streaming package of the FasterXML Jackson suite. It provides the low-level, incremental JSON parser and generator APIs (including the non-blocking/async parser) that jackson-databind and the wider Jackson ecosystem are built on, and is one of the most widely used JSON libraries for Java.

A Denial of Service (DoS) vulnerability (CVE-2026-18401) has been identified in jackson-core, which allows attackers to exhaust memory and processing resources by sending an arbitrarily long numeric literal to the non-blocking (asynchronous) JSON parser, which never enforces the configured number-length limit.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.

This issue affects multiple versions of jackson-core, from 2.15.0 up to and including 2.21.0.

Details

Module Info

Product: jackson-core
Affected packages: com.fasterxml.jackson.core:jackson-core
Affected versions: >=2.15.0 <=2.18.5, >=2.19.0 <2.21.1
GitHub repository: https://github.com/FasterXML/jackson-core
Published packages: https://central.sonatype.com/artifact/com.fasterxml.jackson.core/jackson-core
Package manager: Maven
Fixed in:
- NES for Jackson 2.13.7, 2.14.4, and 2.15.6
- OSS Jackson 2.18.6 and 2.21.1

Vulnerability Info

This Medium-severity vulnerability is found in the com.fasterxml.jackson.core:jackson-core package in multiple 2.x versions of jackson-core. To bound the resources a single document can consume, Jackson exposes StreamReadConstraints.maxNumberLength (default 1000 characters), and the standard blocking parsers enforce it by calling validateIntegerLength(...) and validateFPLength(...) whenever a numeric token is recorded. The non-blocking (asynchronous) parser, obtained from JsonFactory.createNonBlockingByteArrayParser() or createNonBlockingByteBufferParser(), never performs this validation: on every async number path the parser assigns the accumulated digit count directly to its internal length fields and completes the token, so the configured limit is silently skipped.

_intLength = len;   // assigned directly; validateIntegerLength(len) is never called
...
return _valueComplete(JsonToken.VALUE_NUMBER_INT);

Because no length check ever runs on this path, a single numeric literal with millions of digits is accepted and buffered in full, growing the parser's internal text buffer without bound and exhausting JVM heap memory. If the application then calls getBigIntegerValue() or getDecimalValue() on the token, converting the oversized literal costs quadratic CPU time, compounding the denial of service. The non-blocking parser is the API used by reactive and streaming stacks such as Spring WebFlux, so any service that feeds untrusted JSON through it is exposed; the blocking parsers enforce the limit and are not affected by this issue. HeroDevs NES for Jackson had backported StreamReadConstraints to its 2.13.x and 2.14.x lines, so all three NES lines carried the same bypass and all three received the fix.

This vulnerability was introduced in 2023 with jackson-core 2.15.0.

Mitigation

Only recent versions of Jackson Core are community-supported. The affected 2.13.x, 2.14.x, and 2.15.x lines are End-of-Life and will not receive public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

Upgrade jackson-core to a currently supported release that contains the fix, such as 2.18.6 or later.
Leverage a commercial support partner like HeroDevs for post-EOL security support.