CVE-2026-68498

Received Received - Intake

Memory Exhaustion in Jackson Core JSON Parser

Publication date: 2026-10-16

Last updated on: 2026-10-16

Assigner: HeroDevs

Description

StreamReadConstraints.maxNameLength (default 50,000 characters) is intended to bound how much memory a single JSON Object property name can consume while being parsed, independently of the much larger maxStringLength (default 100,000,000 characters) that bounds ordinary string values. For parsers built over character input — Reader, String or char[] sources, all served by ReaderBasedJsonParser — that bound is not applied while the name is being accumulated. The code path instead re-uses the string-value length check, which is roughly 2000x larger by default. In the character-input slow path, ReaderBasedJsonParser._parseName2() accumulates the name into the TextBuffer and, when a segment fills, calls TextBuffer.finishCurrentSegment(), which validates only maxStringLength. The correct check, StreamReadConstraints.validateNameLength(int), is reached afterwards in CharsToNameCanonicalizer.findSymbol(), once the entire name has been scanned to its closing quote. By that point the full name — up to maxStringLength characters — has already been buffered in memory. A remote attacker who can have a single sufficiently long JSON Object property name parsed through this path can force allocation on the order of 100,000,000 characters (approximately 200 MB, with segment bookkeeping pushing real peak usage higher) before any StreamConstraintsException is thrown, instead of the approximately 50,000-character (about 100 KB) bound the API promises. Repeating this across concurrent requests can exhaust the heap and crash the process. No authentication or user interaction is required. Because StreamReadConstraints.maxDocumentLength is disabled by default (-1), nothing else bounds the token first, so the issue is exploitable under default configuration. Byte-input parsers are not affected: UTF8StreamJsonParser, UTF8DataInputJsonParser and the non-blocking (async) parsers re-validate maxNameLength on every growth of the name-decode buffer via ParserBase._growNameDecodeBuffer(), rejecting an oversized name after allocating only tens of kilobytes. Applications are exposed when untrusted JSON is parsed from a String, Reader or char[] — for example an HTTP request body already read into a String — rather than from raw UTF-8 bytes. This issue affects com.fasterxml.jackson.core:jackson-core from 2.16.0 and tools.jackson.core:jackson-core from 3.0.0. Releases before 2.16.0 are not affected, because StreamReadConstraints.maxNameLength was first introduced in jackson-core 2.16.0.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-10-16

Last Modified

2026-10-16

Generated

2026-10-17

AI Q&A

2026-10-17

EPSS Evaluated

N/A

NVD

CVE-2026-68498

Affected Vendors & Products

Vendor	Product	Version / Range
FasterXML	jackson-core	2.16.0
FasterXML	jackson-core	2.19.0
FasterXML	jackson-core	2.22.0
FasterXML	jackson-core	3.0.0
FasterXML	jackson-core	3.2.0

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-400	The product does not properly control the allocation and maintenance of a limited resource.

Attack-Flow Graph

Executive Summary

This vulnerability involves a flaw in the Jackson JSON parser library where the maxNameLength constraint for JSON object property names is not properly enforced when parsing from character-based sources like Strings or Readers. Instead of rejecting oversized names early, the parser allows them to grow up to maxStringLength (100 million characters), consuming excessive memory and potentially crashing the application.

Detection Guidance

Detecting this vulnerability requires checking if your system uses vulnerable versions of jackson-core (2.16.0 or later, or 3.0.0 or later) and parsing untrusted JSON from String, Reader, or char[] sources. Monitor for heap exhaustion or crashes during JSON parsing. No specific commands are provided in the context.

Impact Analysis

An attacker could exploit this by sending a JSON payload with an extremely long property name, causing the application to allocate large amounts of memory. This may lead to denial-of-service conditions, heap exhaustion, or process crashes. Systems parsing untrusted JSON from strings or readers are particularly vulnerable.

Compliance Impact

This vulnerability could lead to denial-of-service attacks by exhausting system memory, potentially causing service disruptions. For GDPR, this may impact availability of personal data processing systems. For HIPAA, it could disrupt healthcare services handling protected health information. Both standards require maintaining availability of critical systems.

Mitigation Strategies

Upgrade jackson-core to a patched version. If using 2.16.0+, apply the latest release. For 3.0.0+, ensure you have version 3.0.1 or later. Avoid parsing untrusted JSON from String, Reader, or char[] sources; use byte streams instead.

Hi! I’m here to help you understand CVE-2026-68498. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70