CVE-2026-89425
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Summary
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
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| FasterXML | jackson-core | 2.8.0 <= 2.18.10 | affected |
| FasterXML | jackson-core | 2.19.0 <= 2.21.6 | affected |
| FasterXML | jackson-core | 2.22.0 <= 2.22.2 | affected |
| FasterXML | jackson-core | 3.0.0 <= 3.1.6 | affected |
| FasterXML | jackson-core | 3.2.0 <= 3.2.2 | affected |
Weaknesses
- CWE-770: CWE-770 Allocation of Resources Without Limits or Throttling
- CWE-400: CWE-400 Uncontrolled Resource Consumption
Workarounds
No StreamReadConstraints or ErrorReportConfiguration setting mitigates this issue on the affected code path. Where possible, avoid JsonFactory.createParser(DataInput) for attacker-supplied content and use createParser(InputStream), createParser(Reader) or a byte-array overload instead; those parser implementations enforce maxErrorTokenLength correctly. Otherwise, bound input size ahead of the parser and cap JVM heap so that a single request cannot exhaust process memory.
References
- https://github.com/FasterXML/jackson-core/security/advisories/GHSA-7hhh-6rmp-j9qf
- https://github.com/FasterXML/jackson-core/pull/1698
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.