GHSA-2m67-wjpj-xhg9

What it actually does

Jackson Core 3.x does not consistently apply StreamReadConstraints.maxDocumentLength across all JSON parser entry points. Oversized documents can therefore be fully accepted and materialized without a StreamConstraintsException, so configured document-size limits fail as an in-parser denial-of-service control and parsers may allocate unbounded memory and CPU while reading attacker-controlled JSON.

Why it matters to the business

Services that rely on Jackson Core 3.x size constraints to bound request or message parsing remain exposed to resource exhaustion: worker threads stall, heap and garbage-collection pressure spike, and APIs or message consumers can become unavailable. The issue is a high-severity availability flaw (CVSS 7.5), is not listed in CISA KEV, has no public exploit maturity, and has been known for several months—so residual risk is mainly unpatched Jackson 3.x parsers behind internet-facing or partner JSON endpoints rather than confirmed mass exploitation.

How an attack unfolds

An attacker identifies an application that deserializes untrusted JSON with Jackson Core 3.x and that depends on maxDocumentLength (or equivalent StreamReadConstraints) as its primary size guard. They submit a well-formed but oversized JSON body or token stream through a parser path that skips the length check. The parser does not throw StreamConstraintsException, continues reading, and drives memory and CPU consumption until the process slows, throws OutOfMemoryError, or otherwise fails, denying service to legitimate clients. No authentication bypass or data theft is implied; impact is availability. Named threat-actor use is not indicated.

How to fix it

Upgrade Jackson Core 3.x to a release that consistently enforces StreamReadConstraints.maxDocumentLength on every public parser factory and read path. Until that upgrade is deployed, enforce hard request and message size limits outside the parser (reverse proxy, API gateway, servlet/container max POST size, broker max message size), reject oversized Content-Length and chunked bodies early, avoid mapping untrusted JSON into unbounded in-memory trees, and apply rate limits and isolation so one noisy client cannot starve the JVM. Prefer streaming or incremental reads with explicit max-token and max-nesting constraints in addition to document length. Confirm the patched artifact is the one actually loaded at runtime (dependency tree, shaded JARs, and fat images).

How to confirm the fix worked

Inventory all Jackson Core 3.x usages (direct and transitive) and note which parser APIs construct JsonParser or ObjectMapper readers. After upgrade, regression-test every ingest path with documents just under and just over the configured maxDocumentLength and verify StreamConstraintsException (or equivalent rejection) on oversized input for all entry points previously used in production. Confirm gateway and container body-size limits still reject oversized payloads before they reach the parser. Review runtime classpath and lockfiles so an older jackson-core 3.x is not still shaded or pinned.

Typical attack path

1. Locate an HTTP, queue, or file-ingest path that parses untrusted JSON with Jackson Core 3.x.
2. Confirm the service sets StreamReadConstraints.maxDocumentLength (or similar) and assumes oversized input will be rejected.
3. Send a well-formed JSON document larger than the configured maxDocumentLength via an affected parser entry point.
4. Observe that parsing proceeds without StreamConstraintsException and that memory or CPU rises.
5. Repeat or parallelize oversized submissions to exhaust heap, stall workers, or crash the process.

How to detect it

This weakness leaves little unique malware residue; look for availability symptoms around JSON parsing rather than a signatured payload. Review access and application logs for unusually large JSON request or message bodies that were accepted (2xx) instead of rejected, correlated with heap exhaustion, GC storms, thread-pool saturation, timeouts, or process restarts. Search application logs and crash dumps for Jackson parser stack frames, missing StreamConstraintsException on oversized input, java.lang.OutOfMemoryError, and repeated oversized POSTs or queue messages to the same JSON endpoints. Packet or WAF logs showing repeated large application/json bodies against parse-heavy routes are supporting evidence. There is no public KEV or named-actor campaign context to pivot on.

• java.lang.OutOfMemoryError
• com.fasterxml.jackson.core.exc.StreamConstraintsException
• com.fasterxml.jackson.core.json
• JsonParser
• ObjectMapper.readTree
• ObjectMapper.readValue
• application/json
• Content-Type: application/json

What your security team should do

• Patch or replace Jackson Core 3.x everywhere it parses untrusted JSON; treat remaining 3.x parsers as an availability control failure, not a theoretical library bug.
• Place independent max body/message size, rate limiting, and memory isolation in front of JSON parsers so library constraints are defense in depth.
• Hunt for internet-facing and high-volume internal JSON endpoints that construct ObjectMapper/JsonFactory without additional size caps.
• Add capacity and error-budget alerts for heap usage, GC, thread pools, and 5xx/timeout spikes on JSON-heavy services.
• Re-test size-limit behavior after each Jackson or framework upgrade so new parser entry points cannot silently skip constraints.