CVE-2026-89425

What it actually does

UTF8DataInputJsonParser._reportInvalidToken() in FasterXML jackson-core unbounded-appends Java identifier characters from a malformed token into a StringBuilder with no max length, never consulting ErrorReportConfiguration.getMaxErrorTokenLength() (default 256). The DataInput parse path (JsonFactory.createParser(DataInput)) therefore materializes the entire offending token in the exception message. StreamReadConstraints do not mitigate this: maxDocumentLength cannot be applied to DataInput sources, and maxStringLength is bypassed because accumulation does not go through ReadConstrainedTextBuffer. The resulting StringBuilder growth, byte-to-char expansion, and internal array doubling can inflate memory far beyond the raw payload and trigger a JVM-wide OutOfMemoryError. The affected class exists from 2.8.0 onward (when createParser(DataInput) was introduced). Sibling parsers such as UTF8StreamJsonParser correctly bound the token.

Why it matters to the business

A remote, unauthenticated request can take down Java services that parse untrusted JSON via DataInput, causing request failures, worker or JVM crashes, restart loops, and availability loss for APIs and batch processors that depend on Jackson. Impact is availability-only (CVSS 7.5, no confidentiality or integrity loss) but operationally severe because jackson-core sits under many frameworks and applications. Exploitation maturity is none, the CVE is not in CISA KEV, it is not associated with ransomware, and EPSS remains low and flat (~0.49% over 30 days). The issue is 19 days old, so treat it as a high-availability patching item rather than an active mass-exploitation emergency, while still prioritizing internet-facing JSON parsers.

How an attack unfolds

An unauthenticated attacker who can reach any component that builds a Jackson parser with JsonFactory.createParser(DataInput) submits JSON containing a malformed token made of a very large run of identifier characters. Parsing fails and UTF8DataInputJsonParser._reportInvalidToken() copies the entire token into the error-message buffer instead of truncating it. Heap usage grows well beyond the input size; the process throws OutOfMemoryError or becomes unresponsive. InputStream-based parsers are not equivalent: the same input is bounded there. No named threat actors or campaigns are associated with this CVE, and there is no public exploit maturity.

How to fix it

Upgrade jackson-core to a vendor- or upstream-patched release that applies ErrorReportConfiguration.getMaxErrorTokenLength() (or an equivalent bound) in UTF8DataInputJsonParser._reportInvalidToken(), matching UTF8StreamJsonParser. Releases before 2.8.0 lack the affected class; 2.8.0 and later on the DataInput path are in scope until patched. If a fixed version is not yet pinned in your distro, stop feeding untrusted DataInput into JsonFactory.createParser(DataInput); parse untrusted JSON via InputStream or Reader APIs that already cap error-token length. Enforce request-body size limits at the proxy, servlet, or framework layer; isolate JSON parsing in a process or container with a tight heap; and fail closed on oversized or non-JSON input. Do not rely on StreamReadConstraints.maxDocumentLength or maxStringLength as a complete fix for this path.

How to confirm the fix worked

Inventory jackson-core versions and call sites of JsonFactory.createParser(DataInput) / UTF8DataInputJsonParser. After upgrade, confirm the patched method consults getMaxErrorTokenLength() and that error messages for invalid tokens stay within the configured cap (default 256 characters). Verify DataInput parsing of untrusted input is either removed or guarded by body-size limits. Watch canaries and load tests for absence of OutOfMemoryError and of multi-megabyte Jackson parse exceptions. Dependency and SBOM scans should flag jackson-core >= 2.8.0 without the fix.

Typical attack path

1. Find a reachable service that deserializes untrusted JSON using Jackson created from a DataInput source.
2. Submit a request whose JSON contains a malformed token that fails recognition and enters error reporting.
3. Force unbounded StringBuilder growth while the parser builds the invalid-token exception text.
4. Exhaust JVM heap (compounded by byte-to-char expansion and buffer doubling) until OutOfMemoryError or process hang.
5. Repeat against remaining instances or autoscaled workers to sustain an availability outage.

How to detect it

This is a memory-exhaustion DoS, not a persistence or implant CVE; look for crash and exception artifacts rather than malware. Search application, GC, and container logs around JSON-handling services for OutOfMemoryError, sudden heap spikes, and Jackson parse failures whose messages are abnormally large (orders of magnitude beyond the usual few-hundred-character invalid-token text). Stack traces naming UTF8DataInputJsonParser or _reportInvalidToken are highly relevant; contrast with UTF8StreamJsonParser traces, which indicate the bounded sibling path. Correlate oversized inbound bodies or DataInput-fed parse jobs with worker deaths, pod OOMKills, and repeated restarts. There are no associated threat-actor TTPs; hunt for the crash pattern itself, especially after 2026-09-23.

• com.fasterxml.jackson.core.json.UTF8DataInputJsonParser
• UTF8DataInputJsonParser._reportInvalidToken
• com.fasterxml.jackson.core.JsonParseException
• Unrecognized token '
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: GC overhead limit exceeded
• JsonFactory.createParser
• com.fasterxml.jackson.core.JsonFactory

What your security team should do

• Prioritize upgrade of jackson-core wherever createParser(DataInput) or UTF8DataInputJsonParser is reachable from untrusted input; do not wait for KEV listing given unauthenticated network DoS.
• Search code and binaries for JsonFactory.createParser(DataInput) and replace untrusted DataInput parsing with InputStream/Reader parsers that already bound error tokens.
• Enforce strict maximum request and message sizes at the edge and application layers so oversized tokens never reach the parser.
• Run JSON parsing in memory-constrained workers with restart budgets so a single OOM cannot take down the whole JVM or node.
• Track jackson-core in SBOM/dependency pipelines and alert on 2.8.0+ until the bounding fix is confirmed.
• Because EPSS is low and exploit maturity is none, treat internet-facing parsers first, then internal consumers, rather than emergency mass-exploitation response.