Jackson Core CVE-2026-68498

The application must parse untrusted JSON from a character-based source - java.lang.String, java.io.Reader, or char[] - which routes through ReaderBasedJsonParser (e.g. an HTTP request body already read into a String). Exploitation is NOT possible when parsing raw UTF-8 bytes via UTF8StreamJsonParser, UTF8DataInputJsonParser, or the non-blocking async parsers, which re-validate maxNameLength on every name-buffer growth. It works against default configuration because StreamReadConstraints.maxDocumentLength is disabled by default (-1), so no other limit bounds the oversized token first. Affected versions are com.fasterxml.jackson.core:jackson-core 2.16.0 onward and tools.jackson.core:jackson-core 3.0.0 onward; releases before 2.16.0 are unaffected because maxNameLength did not yet exist. The primary limiting factor is the character-input requirement - the single most important condition for defenders to check in their deployment.

All signals point to a genuine but bounded availability risk. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent with the description: a remote, unauthenticated, low-complexity attack with pure availability impact (CWE-400 resource exhaustion). No EPSS score, KEV listing, or SSVC decision data was provided, and no public exploit was identified at time of analysis - so exploitation is currently theoretical/not-yet-observed rather than active. This is not a high-CVSS-but-trivial issue: the memory-amplification (promised ~100 KB name bound vs. actual ~200 MB allocation, roughly 2000x) is real and crash-capable under concurrency. However, the realistic footprint is narrower than raw AV:N/PR:N suggests, because exploitation only works when the application feeds untrusted JSON through character-based input (String/Reader/char[] via ReaderBasedJsonParser); byte-input parsers (UTF8StreamJsonParser, UTF8DataInputJsonParser, async) are explicitly unaffected. This is a deployment-dependent limiter not captured by the CVSS vector, so treat raw 7.5 as an upper bound. Patch availability is confirmed via the vendor GHSA advisory and merged PR #1643, which materially lowers priority for anyone able to upgrade.

An attacker sends an HTTP request whose body is read into a Java String and then parsed by a jackson-core 2.16.0+ (or 3.0.0+) application using the character-input path, containing a single JSON object property name of up to ~100,000,000 characters. Because the per-name maxNameLength bound is not applied incrementally on this path, the parser buffers the entire name (~200 MB+) before throwing, and repeating this across concurrent requests exhausts the heap and crashes the process. No public exploit code was identified, but the conditions are simple and require no authentication or user interaction.