# GHSA-2m67-wjpj-xhg9: Jackson Core: Document length constraint bypass in blocking, async, and DataInput parsers

> Jackson Core fails to enforce document length limits in certain parsers, allowing attackers to bypass DoS protections and cause resource exhaustion.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 4 Apr 2026

## What is GHSA-2m67-wjpj-xhg9?

GHSA-2m67-wjpj-xhg9 is a denial of service vulnerability in tools.jackson.core:jackson-core, published on 4 Apr 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

## Summary

Jackson Core 3.x does not consistently enforce `StreamReadConstraints.maxDocumentLength`. Oversized JSON documents can be accepted without a `StreamConstraintsException` in multiple parser entry points, which allows configured size limits to be bypassed and weakens denial-of-service protections.

## Details

Three code paths where `maxDocumentLength` is not fully enforced:

### 1. Blocking parsers skip validation of the final in-memory buffer

Blocking parsers validate only previously processed buffers, not the final in-memory buffer:

- `ReaderBasedJsonParser.java:255`
- `UTF8StreamJsonParser.java:208`

Relevant code:

```java
_currInputProcessed += bufSize;
_streamReadConstraints.validateDocumentLength(_currInputProcessed);
```

This means the check occurs only when a completed buffer is rolled over. If an oversized document is fully contained in the final buffer, parsing can complete without any document-length exception.

### 2. Async parsers skip validation of the final chunk on end-of-input

Async parsers validate previously processed chunks, but do not validate the final chunk on end-of-input:

- `NonBlockingByteArrayJsonParser.java:49`
- `NonBlockingByteBufferJsonParser.java:57`
- `NonBlockingUtf8JsonParserBase.java:75`

Relevant code:

```java
_currInputProcessed += _origBufferLen;
_streamReadConstraints.validateDocumentLength(_currInputProcessed);

public void endOfInput() {
    _endOfInput = true;
}
```

`endOfInput()` marks EOF but does not perform a final `validateDocumentLength(...)` call, so an oversized last chunk is accepted.

### 3. DataInput parser path does not enforce `maxDocumentLength` at all

- `JsonFactory.java:457`

Relevant construction path:

```java
int firstByte = ByteSourceJsonBootstrapper.skipUTF8BOM(input);
return new UTF8DataInputJsonParser(readCtxt, ioCtxt,
        readCtxt.getStreamReadFeatures(_streamReadFeatures),
        readCtxt.getFormatReadFeatures(_formatReadFeatures),
        input, can, firstByte);
```

`UTF8DataInputJsonParser` does not call `StreamReadConstraints.validateDocumentLength(...)`, so `maxDocumentLength` is effectively disabled for `createParser(..., DataInput)` users.

> **Note:** This issue appears distinct from the recently published nesting-depth and number-length constraint advisories because it affects document-length enforcement.

## PoC

### Async path reproducer

```java
import java.nio.charset.StandardCharsets;
import tools.jackson.core.JsonParser;
import tools.jackson.core.ObjectReadContext;
import tools.jackson.core.StreamReadConstraints;
import tools.jackson.core.async.ByteArrayFeeder;
import tools.jackson.core.json.JsonFactory;

public class Poc {
    public static void main(String[] args) throws Exception {
        JsonFactory factory = JsonFactory.builder()
                .streamReadConstraints(StreamReadConstraints.builder()
                        .maxDocumentLength(10L)
                        .build())
                .build();

        byte[] doc = "{\"a\":1,\"b\":2}".getBytes(StandardCharsets.UTF_8);

        try (JsonParser p = factory.createNonBlockingByteArrayParser(ObjectReadContext.empty())) {
            ByteArrayFeeder feeder = (ByteArrayFeeder) p.nonBlockingInputFeeder();
            feeder.feedInput(doc, 0, doc.length);
            feeder.endOfInput();

            while (p.nextToken() != null) { }
        }

        System.out.println("Parsed successfully");
    }
}
```

- **Expected result:** Parsing should fail because the configured document-length limit is 10, while the input is longer than 10 bytes.
- **Actual result:** The document is accepted and parsing completes.

### Blocking path reproducer

```java
import java.io.ByteArrayInputStream;
import java.nio.charset.StandardCharsets;
import tools.jackson.core.JsonParser;
import tools.jackson.core.StreamReadConstraints;
import tools.jackson.core.json.JsonFactory;

public class Poc2 {
    public static void main(String[] args) throws Exception {
        JsonFactory factory = JsonFactory.builder()
                .streamReadConstraints(StreamReadConstraints.builder()
                        .maxDocumentLength(10L)
                        .build())
                .build();

        byte[] doc = "{\"a\":1,\"b\":2}".getBytes(StandardCharsets.UTF_8);

        try (JsonParser p = factory.createParser(new ByteArrayInputStream(doc))) {
            while (p.nextToken() != null) { }
        }

        System.out.println("Parsed successfully");
    }
}
```

## Impact

Applications that rely on `maxDocumentLength` as a safety control for untrusted JSON can accept oversized inputs without error. In network-facing services this weakens an explicit denial-of-service protection and can increase CPU and memory consumption by allowing larger-than-configured request bodies to be processed.

## Which versions are affected by GHSA-2m67-wjpj-xhg9?

2 open source packages ship an affected version, including tools.jackson.core:jackson-core.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `tools.jackson.core:jackson-core` | Maven | From 3.0.0 | 3.1.1 |
| `tools.jackson.core:jackson-core` | Maven | From 3.0.0 | 3.1.1 |

## How do I fix GHSA-2m67-wjpj-xhg9?

Upgrade tools.jackson.core:jackson-core to 3.1.1 or later.

## Is GHSA-2m67-wjpj-xhg9 being exploited?

There is no known exploitation of GHSA-2m67-wjpj-xhg9 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-2m67-wjpj-xhg9 and fix it if it is affected.

What it is: GHSA-2m67-wjpj-xhg9 is a denial of service vulnerability in tools.jackson.core:jackson-core, published on 4 Apr 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-2m67-wjpj-xhg9 in the wild and no public exploit code.

Affected packages and fixed versions:
- tools.jackson.core:jackson-core (Maven): affected from 3.0.0; fixed in 3.1.1
- tools.jackson.core:jackson-core (Maven): affected from 3.0.0; fixed in 3.1.1

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-2m67-wjpj-xhg9/ (Markdown: https://insights.sbomify.com/GHSA-2m67-wjpj-xhg9/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-2m67-wjpj-xhg9

---
From sbomify Insights: https://insights.sbomify.com/GHSA-2m67-wjpj-xhg9/
Summaries are generated and may contain mistakes; the official description above is the record.