CVE-2026-89425

Overview

jackson-core is the core streaming package of the FasterXML Jackson suite. It provides the low-level, incremental JSON parser and generator APIs (including the non-blocking/async parser) that the higher-level Jackson databind and dataformat modules are built on.

A Denial of Service (DoS) vulnerability (CVE-2026-89425) has been identified in the DataInput-backed streaming parser of jackson-core, which allows attackers to make the parser accumulate an entire malformed token into a single exception message, so that a small, cheaply generated payload drives heap allocation and message construction proportional to the attacker-controlled input and can exhaust available memory.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others. If a service receives a very large number of requests, it may cease to be available to legitimate users. In the same way, a service may stop if a programming vulnerability is exploited, or the way the service handles resources it uses.

This issue affects the DataInput-backed JSON parsing path of Jackson, reached whenever an application creates parsers from a java.io.DataInput source.

Details

Module Info

• Product: Jackson
• Affected packages: com.fasterxml.jackson.core:jackson-core, tools.jackson.core:jackson-core
• Affected versions: com.fasterxml.jackson.core:jackson-core >=2.8.0 <2.18.11, >=2.19.0 <2.21.7, >=2.22.0 <2.22.3; tools.jackson.core:jackson-core >=3.0.0 <3.1.7, >=3.2.0 <3.2.3
• GitHub repository: https://github.com/FasterXML/jackson-core
• Published packages: https://central.sonatype.com/artifact/com.fasterxml.jackson.core/jackson-core
• Package manager: Maven
• Fixed in:
  • NES for Jackson 2.13.x, 2.14.x, and 2.15.x
  • OSS jackson-core 2.18.11, 2.21.7, and 2.22.3
  • OSS tools.jackson.core:jackson-core 3.1.7 and 3.2.3

Vulnerability Info

This High-severity vulnerability is found in the com.fasterxml.jackson.core:jackson-core package in the DataInput-backed streaming JSON parser of Jackson.

When the parser meets bytes that do not form a valid JSON value, it tries to describe the offending token in the error it raises. The DataInput implementation builds that description by reading identifier characters one at a time and appending each of them to a StringBuilder, with no upper bound on how many characters it will collect:

protected void _reportInvalidToken(int ch, String matchedPart, String msg)
    throws IOException
 {
     StringBuilder sb = new StringBuilder(matchedPart);

     /* Let's just try to find what appears to be the token, using
      * regular Java identifier character rules. It's just a heuristic,
      * nothing fancy here (nor fast).
      */
     while (true) {
         char c = (char) _decodeCharForError(ch);
         if (!Character.isJavaIdentifierPart(c)) {
             break;
         }
         sb.append(c);
         ch = _inputData.readUnsignedByte();
     }
     _reportError("Unrecognized token '"+sb.toString()+"': was expecting "+msg);
 }

The loop only stops when the stream yields a character that is not a Java identifier part, so the length of the accumulated text is chosen entirely by the caller supplying the document. An attacker who can submit JSON to an endpoint that parses from a java.io.DataInput source only has to send an unterminated word, for example a value that begins with the letter t and then continues with millions of identifier characters instead of completing the literal true. Every one of those characters is appended, the resulting string is then embedded into the exception message, and the error path allocates and copies memory in proportion to the payload rather than in proportion to a fixed error budget. The advisory reports an exception message of 20,000,109 characters produced from a 20 million character payload on this path.

The three sibling parser implementations in jackson-core stop collecting once the accumulated text reaches the error token limit, so the defect is specific to the DataInput-backed parser. No parser configuration closes the gap on this path either, because the document length limit is not supported for DataInput sources and the string length limit does not apply to characters gathered here.

This vulnerability was introduced in 2016 with Jackson 2.8.0.

Steps to Reproduce

1. Add com.fasterxml.jackson.core:jackson-core in an affected version to a Java project.

2. Build a malformed JSON document whose value starts an identifier that is never completed, and wrap it in a java.io.DataInput:

InputStream filler = new InputStream() {
    private long left = 20_000_000L;
    @Override public int read() { return (left-- > 0) ? 'x' : -1; }
};

InputStream raw = new SequenceInputStream(
        new ByteArrayInputStream("{\"a\": t".getBytes("UTF-8")),
        new SequenceInputStream(
                filler,
                new ByteArrayInputStream(" }".getBytes("UTF-8"))));

JsonParser p = new JsonFactory().createParser((DataInput) new DataInputStream(raw));
try {
    p.nextToken(); p.nextToken(); p.nextToken();
} catch (JsonParseException e) {
    System.out.println("message length: " + e.getOriginalMessage().length());
}

3. Run the program and observe that the reported message length tracks the payload size rather than the default error token limit of 256 characters.

4. Feed the identical bytes to new JsonFactory().createParser(raw) instead, and observe a bounded message of a few hundred characters, confirming that only the DataInput-backed parser is affected.

Mitigation

The affected 2.13.x, 2.14.x, and 2.15.x release lines are End-of-Life and will not receive community updates addressing this issue. Branch status is published on the project's own Jackson Releases page.

Users of the affected components should apply one of the following mitigations:

• Upgrade jackson-core to a currently supported release containing the fix, such as 2.18.11, 2.21.7, or 2.22.3.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

manqingzhou (finder)