CVE-2026-68498: jackson-core: Delayed maxNameLength enforcement for char-backed input (ReaderBasedJsonParser) allows memory-exhaustion denial of service

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.

Text from the CVE.org record (HeroDevs).

How do I fix CVE-2026-68498?

Upgrade to a fixed release named by the vendor:

• Atlassian: Crowd Data Center and Server: 7.2.4 recommended Data Center Only
• Red Hat: ocp-tools-4/jenkins-rhel8:1792044386, ocp-tools-4/jenkins-rhel9:1792040096, ocp-tools-4/jenkins-rhel9:1792040287, ocp-tools-4/jenkins-rhel9:1792040131, ocp-tools-4/jenkins-rhel8:1792044327, ocp-tools-4/jenkins-rhel8:1792044326

• Upgrade to a fixed version listed by Atlassian: Crowd Data Center and Server: 7.2.4 recommended Data Center Only. (Atlassian)
• Parse untrusted JSON payloads directly from UTF-8 byte streams (e.g., InputStream or raw bytes) rather than character-based sources like String or Reader. Alternatively, configure custom StreamReadConstraints to lower maxStringLength or enforce a strict maxDocumentLength limit on custom JsonFactory instances. --- CME Mitigation Guidance (2026-10-20) --- Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure. The highest-value action is to enforce property name length limits during incremental segment accumulation in ReaderBasedJsonParser character-input parsing paths: upgrade to jackson-core 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2 (or the fixed Maven/Jackson Core/Pki Deps:10.6/Jackson Core/Rhaiis/Vllm Cuda Rhel/Rhaii/Vllm Gaudi Rhel/Ansible Automation Platform 25/De Minimal Rhel/Ansible Automation Platform 27/De Supported Rhel/Ansible Automation Platform 26/De Minimal Rhel/Ansible Automation Platform 27/De Minimal Rhel/Log4J/Exploit Intelligence/Agent Client Rhel/Jackson Bom/Jboss Webserver 7/Jws70 Openjdk17 Openshift Rhel/Ocp Tools 4/Jenkins Rhel/Jboss Webserver 7/Jws70 Openjdk21 Openshift Rhel/Offline Knowledge Portal/Rhokp Rhel/Rhoai/Odh Vllm Gaudi Rhel/Rhoai/Odh Trustyai Service Rhel/Rhoai/Odh Spark Operator Rhel/Rhoai/Odh Modelmesh Rhel/Rhoai/Odh Th06 Cpu Torch291 Py312 Rhel/Rhoai/Odh Th06 Cuda130 Torch210 Py312 Rhel/Rhoai/Odh Th06 Cuda130 Torch291 Py312 Rhel/Rhoai/Odh Th06 Cpu Torch210 Py312 Rhel/Rhoai/Odh Th06 Rocm64 Torch291 Py312 Rhel/Rhoai/Odh Th Torch Cuda Py312 Rhel/Rhoai/Odh Th Torch Cpu Py312 Rhel/Rhai Early Access/Docling Serve Cuda Rhel/Rhbk/Keycloak Rhel/Rhbk/Keycloak Rhel9 Operator/Rhelai3/Bootc Gaudi Rhel/Devspaces/Openvsx Rhel/Devspaces/Pluginregistry Rhel/Devspaces/Multicluster Redirector Rhel/Devspaces/Server Rhel/Openshift Serverless 1/Kn Eventing Integrations Aws S3 Sink Rhel/Openshift Serverless 1/Kn Eventing Integrations Aws Ddb Streams Source Rhel/Openshift Serverless 1/Kn Eventing Integrations Aws Sqs Sink Rhel/Openshift Serverless 1/Kn Eventing Integrations Aws Sns Sink Rhel/Openshift Serverless 1/Kn Eventing Integrations Log Sink Rhel/Openshift Serverless 1/Kn Eventing Integrations Aws S3 Source Rhel/Openshift Serverless 1/Kn Eventing Integrations Aws Sqs Source Rhel/Openshift Serverless 1/Kn Eventing Integrations Timer Source Rhel/Cloudservices/Insights Rbi Events/Cloudservices/Kafka Relations Sink/Cloudservices/Insights Rbi Rest/Cloudservices/Rhsm Auto Registration Listener/Cloudservices/Notifications Backend/Cloudservices/Notifications Gw/Cloudservices/Swatch Producer Azure/Cloudservices/Swatch Contracts/Cloudservices/Swatch Producer Aws/Cloudservices/Swatch Utilization/Cloudservices/Swatch Metrics builds), which track accumulated name length in _parseName2() and _handleOddName2() and invoke validateNameLength() when a buffer segment fills, closing all 2 injection vectors (crafted JSON payload with excessively long object property name, concurrent requests with oversized JSON keys targeting character-based parsers). Until patched, this is a concern on applications parsing untrusted JSON from character-based sources such as String, Reader, or char[], so parse untrusted JSON directly from UTF-8 byte streams such as InputStream rather than character sources, or configure custom StreamReadConstraints to lower maxStringLength and enforce maxDocumentLength. As a compensating measure, monitor cgroup memory pressure via memory.events and PSI thresholds to detect rapid memory spikes prior to process termination, set ulimit or prlimit process resource limits to constrain address space consumption caused by oversized property name buffering, apply cgroups v2 resource limits to contain the blast radius of JVM heap exhaustion to the affected container or process group, and throttle client request rates and connection volume to impede concurrent transmissions of oversized JSON keys. These controls limit blast radius and contain exploitation, but they do not fix the underlying unbounded memory buffering defect — apply the upstream patch to fully remediate. Highest-impact CME: CME-1010 cgroup Memory Pressure Monitoring (memory.events / PSI) (medium) (Red Hat)