jackson-core: UTF8DataInputJsonParser._reportInvalidToken() does not honor maxErrorTokenLength, allowing unbounded StringBuilder growth
Summary
| CVE | CVE-2026-89425 |
|---|---|
| State | PUBLISHED |
| Assigner | HeroDevs |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-09-23 03:17:04 UTC |
| Updated | 2026-09-24 20:43:32 UTC |
| Description | 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. |
Risk And Classification
Primary CVSS: v3.1 7.5 HIGH from 36c7be3b-2937-45df-85ea-ca7133ea542c
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS: 0.004920000 probability, percentile 0.397100000 (date 2026-09-25)
Problem Types: CWE-400 | CWE-770 | CWE-770 CWE-770 Allocation of Resources Without Limits or Throttling | CWE-400 CWE-400 Uncontrolled Resource Consumption
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | 36c7be3b-2937-45df-85ea-ca7133ea542c | Secondary | 7.5 | HIGH | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| 3.1 | CNA | CVSS | 7.5 | HIGH | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
CVSS v3.1 Breakdown
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | FasterXML | Jackson-core | affected 2.8.0 2.18.10 maven | Not specified |
| CNA | FasterXML | Jackson-core | affected 2.19.0 2.21.6 maven | Not specified |
| CNA | FasterXML | Jackson-core | affected 2.22.0 2.22.2 maven | Not specified |
| CNA | FasterXML | Jackson-core | affected 3.0.0 3.1.6 maven | Not specified |
| CNA | FasterXML | Jackson-core | affected 3.2.0 3.2.2 maven | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| github.com/FasterXML/jackson-core/pull/1698 | 36c7be3b-2937-45df-85ea-ca7133ea542c | github.com | |
| github.com/FasterXML/jackson-core/security/advisories/GHSA-7hhh-6rmp-j9qf | 134c704f-9b21-4f2e-91b3-4a467353bcc0 | github.com | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
Vendor Comments And Credit
Discovery Credit
CNA: manqingzhou (en)
Additional Advisory Data
Solutions
CNA: Upgrade to com.fasterxml.jackson.core:jackson-core 2.18.11, 2.21.7 or 2.22.3, or to tools.jackson.core:jackson-core 3.1.7 or 3.2.3. The 2.8.x through 2.17.x, 2.19.x, 2.20.x and 3.0.x lines received no fix on their own branch and are no longer maintained upstream; consumers of those lines must move forward to a maintained release.
Workarounds
CNA: 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.