CyberSecBulletin
CVE-2026-68498NVD status: Deferred

jackson-core: Uncontrolled Resource Consumption

Published Updated By the CyberSecBulletin desk

CVE-2026-68498 is a high-severity uncontrolled resource consumption vulnerability in jackson-core from FasterXML, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions 2.18.10, 2.21.6, 2.22.2 as the first without the flaw, so updating jackson-core to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.65% chance of exploitation within 30 days, higher than 52% of scored CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update jackson-core to 2.18.10 or 2.21.6 or 2.22.2 or 3.1.6, whichever matches your release line, or a later version.
  2. Read the advisory on github.com for workarounds and exact fixed builds.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
FasterXMLjackson-core2.16.0 up to, but not including, 2.18.10; 2.19.0 up to, but not including, 2.21.6; 2.22.0 up to, but not including, 2.22.2; 3.0.0 up to, but not including, 3.1.6; 3.2.0 up to, but not including, 3.2.22.18.10, 2.21.6, 2.22.2, 3.1.6, 3.2.2

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
NoneNo data is disclosed.
Integrity
NoneNothing can be modified.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Scored by CNA.

Official 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.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Uncontrolled Resource Consumption

The product does not properly control the allocation and maintenance of a limited resource.

How developers prevent this class of flaw

  • Ensure that protocols have specific limits of scale placed on them.
  • Ensure that all failures in resource allocation place the system into a safe posture.

More Uncontrolled Resource Consumption vulnerabilities (CWE-400)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: partial).
  3. Record last changed materially (score, affected products, status or references).

References

Other vulnerabilities in jackson-core

All jackson-core vulnerabilities

Recent Uncontrolled Resource Consumption vulnerabilities

Spotted an error? Tell us.