CVE-2026-89425: 
Linux Debian Analyse et atténuation des vulnérabilités

CVE-2026-89425 is a Denial of Service vulnerability in FasterXML jackson-core caused by unbounded StringBuilder growth in UTF8DataInputJsonParser._reportInvalidToken(). When a malformed token is supplied to a parser created via JsonFactory.createParser(DataInput), the method accumulates the full offending token text without enforcing the ErrorReportConfiguration.getMaxErrorTokenLength() limit (default 256 characters), unlike the three sibling parser implementations. Affected versions include com.fasterxml.jackson.core:jackson-core 2.8.0–2.18.10, 2.19.0–2.21.6, and 2.22.0–2.22.2, as well as tools.jackson.core:jackson-core 3.0.0–3.1.6 and 3.2.0–3.2.2; versions prior to 2.8.0 are unaffected as UTF8DataInputJsonParser did not exist. The vulnerability was disclosed on September 22–23, 2026, and carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). In UTF8DataInputJsonParser._reportInvalidToken(), Java identifier characters are appended one at a time to a bare StringBuilder in an unbounded while(true) loop with no check against ErrorReportConfiguration.getMaxErrorTokenLength(). The three sibling parsers — UTF8StreamJsonParser, ReaderBasedJsonParser, and NonBlockingUtf8JsonParserBase — all correctly enforce this limit by appending "..." and breaking when the cap is reached. No StreamReadConstraints setting can mitigate this path: maxDocumentLength is explicitly rejected for DataInput sources, and maxStringLength does not apply because the accumulation bypasses ReadConstrainedTextBuffer. The fix, implemented in PR #1698, mirrors the existing bound from UTF8StreamJsonParser into the DataInput variant (GitHub Advisory, GitHub PR #1698).

Successful exploitation causes unbounded heap memory consumption, which can trigger an OutOfMemoryError that crashes the entire JVM process, resulting in a complete denial of service for all applications running in that JVM. A 20-million-character malformed token was demonstrated to produce a 20,000,109-character exception message (roughly 54,500× the bounded output of the InputStream path), and scaling to gigabyte-sized payloads — well within typical unbounded HTTP request bodies — would drive memory consumption to many times the raw payload size due to byte-to-char expansion and internal StringBuilder array doubling. There is no impact on confidentiality or integrity; the vulnerability is limited to availability (GitHub Advisory).

Exploitation requires no authentication, no privileges, and no user interaction — the only precondition is that the target application creates JSON parsers via JsonFactory.createParser(DataInput) over attacker-controlled input, which is a fully public, non-deprecated API. No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory, Red Hat Bugzilla).

1. Identify target: Locate a Java application that parses JSON from a DataInput source using JsonFactory.createParser(DataInput) and accepts attacker-controlled input (e.g., via an HTTP endpoint that reads a request body into a DataInputStream).
2. Craft malformed payload: Construct a JSON document containing a malformed token — specifically, a token that begins with a character matching the start of a keyword (e.g., t for true) followed by a very long sequence of valid Java identifier characters (e.g., millions of x characters), then a terminating non-identifier character. Example: {"a": t + x × 20,000,000 + }.
3. Deliver payload: Send the crafted payload to the target endpoint. No authentication or special headers are required.
4. Trigger unbounded accumulation: The parser's _reportInvalidToken() method enters its unbounded loop, appending each identifier character to a StringBuilder without limit, consuming heap memory proportional to the payload size (amplified by byte-to-char expansion and array doubling).
5. Achieve DoS: At sufficient payload scale, the JVM exhausts heap memory and throws OutOfMemoryError, crashing the entire JVM process and denying service to all co-hosted applications (GitHub Advisory).

• Logs: JVM crash logs or application logs containing java.lang.OutOfMemoryError: Java heap space originating from UTF8DataInputJsonParser._reportInvalidToken() or com.fasterxml.jackson.core.json.UTF8DataInputJsonParser; JsonParseException messages with extremely long "Unrecognized token" strings (millions of characters).
• Application Behavior: Sudden JVM process termination or unresponsiveness in services that accept JSON input; heap dump files (e.g., java_pid*.hprof) generated at crash time showing large StringBuilder or char[] allocations.
• Network: Inbound HTTP requests with unusually large bodies (tens of megabytes to gigabytes) directed at JSON-parsing endpoints; requests that do not complete normally but cause service restarts.
• Process: Rapid heap growth visible in JVM monitoring tools (e.g., JConsole, VisualVM, Prometheus JVM metrics) immediately preceding an OOM crash, without a corresponding increase in legitimate application load (GitHub Advisory).

Upgrade to a patched version of jackson-core: com.fasterxml.jackson.core:jackson-core 2.18.11, 2.21.7, or 2.22.3; or tools.jackson.core:jackson-core 3.1.7 or 3.2.3. If an immediate upgrade is not possible, avoid using JsonFactory.createParser(DataInput) with untrusted input and route JSON parsing through createParser(InputStream) instead, which correctly enforces maxErrorTokenLength. Additionally, implement network-level or application-level request body size limits to reduce the maximum feasible payload size. Note that StreamReadConstraints.maxDocumentLength() and maxStringLength() cannot mitigate this specific code path and should not be relied upon as workarounds (GitHub Advisory, GitHub PR #1698).

The vulnerability was reported by researcher manqingzhou and the fix was implemented by contributor pjfanning and merged by jackson-core maintainer cowtowncoder on September 11, 2026. The maintainer noted in the PR that the drift went unnoticed because ErrorReportConfigurationTest only exercised the ReaderBasedJsonParser path and never reached the DataInput path, and that this follows a prior pattern of the DataInput-backed parser missing constraints honored by other implementations (referencing a similar prior issue with max depth validation). No significant broader media coverage or social media discussion has been identified at this time (GitHub PR #1698).