7.5

GHSA-2M67-WJPJ-XHG9: jackson-core Maven

Published
Published 04-04-2026Last modified 10-09-2026

Vulnerability summary

GHSA-2M67-WJPJ-XHG9 is a high (CVSS 7.5) vulnerability in jackson-core Maven.

Priority
Prioritisesevere

Severe, CVSS 7.5 (OSV · Maven); no exploitation reported by the 5 checked sources; EPSS not yet published

Source freshness unavailable

How is this decided?
CVSS score
7.5/10
010
High · v3.1 (OSV · Maven), selected by version preference
EPSS scoreNot scoredRisk metrics not yet published.
KEVNot listedNot listed by any tracked catalog.
RansomwareNot flaggedNo ransomware use recorded.
Public exploits0No public exploits recorded

Advisory lineage

Upstream 0 · Downstream 52 · Related 1

Timeline

  1. 04-04-2026
    PublishedVulnerability first disclosed.
  2. 10-09-2026
    Last modifiedVulnerability information updated.

Description

Jackson Core: Document length constraint bypass in blocking, async, and DataInput parsers ## 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.

CVSS metrics

1 score · 1 source · 1 version

EPSS trend

No EPSS score has been published for this record yet.

Known exploited

Compare KEV catalogs
CISA KEV

Not in the CISA KEV catalog.

ENISA CNW

Not in the ENISA CNW catalog.

CIRCL

Not in the CIRCL catalog.

Public exploits

0 found

No public exploits indexed.

Weaknesses

CWE · root cause

No weakness data has been published for this record.

Affected systems

Version check

Known conditions: network-reachable, no authentication, no user interaction (CVSS vector). Other conditions: not stated in public data.

Tools.jackson.core1 product
  • jackson-core≥ 3.0.0, < 3.1.1

1 vendor · 1 product

References

3 links