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:255UTF8StreamJsonParser.java:208
Relevant code:
_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:49NonBlockingByteBufferJsonParser.java:57NonBlockingUtf8JsonParserBase.java:75
Relevant code:
_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:
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
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
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.
Czego dotyczy
Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.
| Platforma | Paczka | Podatne wersje | Poprawka w wersji |
|---|---|---|---|
| Java / Kotlin (Maven) | tools.jackson.core:jackson-core | >= 3.0.0, < 3.1.1 | 3.1.1 |
Odnośniki
- Wektor CVSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H- Słabość (CWE)
CWE-770- Platforma
- Java / Kotlin (Maven)
- Paczka
tools.jackson.core:jackson-core- Ujawniono
- 04.04.2026
- Aktualizacja
- 11.10.2026 13:20
Źródła i licencje
OSV / GitHub Advisory Database - GHSA-2m67-wjpj-xhg9 - CC BY 4.0
Historia podatności: tools.jackson.core:jackson-core
Wszystkie opisane podatności tej paczki (Java / Kotlin (Maven)), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.
- Wszystkich wpisów
- 6
- Pierwsza → ostatnia
- 02.2026 10.2026
- Bez poprawki
- 0
- Wykorzystywana w atakach
- 0
Rozkład istotności
- Wysoka 5
- Średnia 1
Ujawnienia w latach
- 2026: 6
-
Jackson Core: Document length constraint bypass in blocking, async, and DataInput parsers ten wpis
Dowiedz się, które podatności dotyczą Twojej aplikacji
Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.