CVE-2026-89425: jackson-core: UTF8DataInputJsonParser._reportInvalidToken() does not honor maxErrorTokenLength, allowing unbounded StringBuilder growth
UTF8DataInputJsonParser.reportInvalidToken() in FasterXML jackson-core builds the offending-token text for its error message by appending Java identifier characters to a StringBuilder in a loop that has no upper bound. Unlike the three sibling parser implementations, including UTF8StreamJsonParser, it never consults ErrorReportConfiguration.getMaxErrorTokenLength() (default 256). A malformed token supplied to a parser created through JsonFactory.createParser(DataInput) is therefore accumulated in full. No StreamReadConstraints setting mitigates this: maxDocumentLength cannot be applied to DataInput sources at all, and maxStringLength does not cover this path because the accumulation bypasses ReadConstrainedTextBuffer. The reporter measured a 20,000,109-character exception message from a 20-million-character malformed token on the DataInput path, against 367 characters for identical input on the InputStream path. Scaling the payload drives the StringBuilder, which also incurs byte-to-char expansion and internal array doubling, to many times the raw payload size and can trigger OutOfMemoryError for the whole JVM. UTF8DataInputJsonParser was introduced in 2.8.0 together with createParser(DataInput); releases before 2.8.0 do not contain the affected class.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
com.fasterxml.jackson.core:jackson-coreto a version that resolves this vulnerability.Fixed in 2.18.11
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments are exposed when untrusted input is parsed through JsonFactory.createParser(DataInput), causing use of UTF8DataInputJsonParser. The affected parser was introduced in version 2.8.0.
What must an attacker provide to trigger the resource exhaustion?
An attacker needs to supply a malformed token containing a large sequence of Java identifier characters to a parser using the DataInput path. No privileges or user interaction are required according to the supplied CVSS vector.
Does the default error-token limit prevent exploitation?
No. Although maxErrorTokenLength defaults to 256, UTF8DataInputJsonParser does not consult that setting, so the malformed token is accumulated in full for the exception message.
Do StreamReadConstraints mitigate the issue?
No. maxDocumentLength cannot be applied to DataInput sources, and maxStringLength does not cover this error-reporting path because it bypasses ReadConstrainedTextBuffer.
What can be done before a fix is deployed?
Avoid parsing attacker-controlled data through JsonFactory.createParser(DataInput). The InputStream parser path does not show the same unbounded error-token accumulation; the reported 20-million-character malformed input produced a 367-character exception message on that path.