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.
Published: 2026-10-16
Score: 7.5 High
EPSS: n/a
KEV: No
Impact: Memory exhaustion denial of service
Action: Apply Patch
AI Analysis

Impact

Parser components that build JSON from character sources such as Reader, String, or char[] (all provided by ReaderBasedJsonParser) neglect the maxNameLength limit while accumulating property names. The name buffer grows until the name completes, only then validating the name length against maxNameLength. Because the early validation uses the larger maxStringLength bound (100 million characters), an attacker can supply an object key large enough to trigger allocations of about 200 MB before an exception is thrown, exhausting the application's heap.

Affected Systems

All builds of FasterXML jackson-core starting with 2.16.0 and the 3.0.0 release are affected. The issue exists for the com.fasterxml.jackson.core and tools.jackson.core variants. Applications that consume untrusted JSON from String, Reader, or char[] sources—such as HTTP request bodies read into strings—are exposed, while raw UTF‑8 byte parsers are unaffected.

Risk and Exploitability

The CVSS score is 7.5, indicating high severity. No EPSS value is provided, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires no authentication and can be performed remotely simply by delivering a long property name in a JSON document that goes through the character‑based parsing path. Repeated or concurrent requests can cause heap exhaustion and crash the JVM, providing a denial of service to all users of the affected application.

Generated by OpenCVE AI on October 16, 2026 at 22:31 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade jackson-core to the latest stable release that fixes the name‑length enforcement issue.
  • Configure the application to read JSON from a raw UTF‑8 byte stream instead of from a string or Reader whenever possible.
  • Reduce the StreamReadConstraints.maxNameLength setting to a stricter value (e.g., 1 000 characters) if the application accepts only short property names and cannot upgrade immediately.
  • Monitor JVM memory usage and set appropriate heap limits to mitigate impact while the vulnerability is addressed.

Generated by OpenCVE AI on October 16, 2026 at 22:31 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 17 Oct 2026 00:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-770
References
Metrics threat_severity

None

 threat_severity

Important

Fri, 16 Oct 2026 21:30:00 +0000

Type Values Removed Values Added
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.
Title jackson-core: Delayed maxNameLength enforcement for char-backed input (ReaderBasedJsonParser) allows memory-exhaustion denial of service
Weaknesses CWE-400
References
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: HeroDevs

Published:

Updated: 2026-10-16T21:11:03.551Z

Reserved: 2026-07-30T15:20:37.473Z

Link: CVE-2026-68498

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-16T22:17:25.183

Modified: 2026-10-16T22:17:25.183

Link: CVE-2026-68498

cve-icon Redhat

Severity : Important

Publid Date: 2026-10-16T21:11:03Z

Links: CVE-2026-68498 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-16T22:45:14Z

Weaknesses
  • CWE-400

    Uncontrolled Resource Consumption

  • CWE-770

    Allocation of Resources Without Limits or Throttling