Jackson Core
Monthly
Memory exhaustion in jackson-core's non-blocking async parser allows remote unauthenticated attackers to exhaust JVM heap by streaming JSON integer digit sequences in small chunks without ever sending a terminator byte. The prior fix for GHSA-72hv-8253-57qq (CVE-2026-18401) failed to insert a `validateIntegerLength()` call on the `NOT_AVAILABLE` return path inside `MINOR_NUMBER_INTEGER_DIGITS`, allowing the internal `TextBuffer` accumulator to grow bounded only by `maxStringLength` (20 MiB default) rather than `maxNumberLength` (1000 chars default) - a ~20,000x amplification yielding approximately 40 MiB of heap pressure per connection due to Java's 2-byte char representation. Reactive frameworks that feed inbound HTTP or gRPC bytes incrementally to the async parser - Spring WebFlux/Reactor, Quarkus, Helidon, and Vert.x - are the primary risk surface; no public exploit identified at time of analysis.
Uncontrolled-recursion denial of service in FasterXML jackson-core 3.0.0 through 3.0.x lets a remote attacker crash JSON-processing services by submitting a deeply nested JSON document. The UTF8DataInputJsonParser (DataInput sources) and ReaderBasedJsonParser fail to enforce the StreamReadConstraints maxNestingDepth limit (default 500), so excessive nesting drives a StackOverflowError. No public exploit identified at time of analysis and EPSS is low (0.06%), but the bug is trivially triggerable against any service that parses untrusted JSON with these parsers; fixed in 3.1.0.
Denial of service in FasterXML jackson-core's non-blocking (async) JSON parser allows unauthenticated network attackers to exhaust JVM heap and CPU by submitting JSON containing arbitrarily long number tokens that bypass the maxNumberLength constraint. Affected deployments are those using the async parser API - particularly reactive frameworks such as Spring WebFlux - running com.fasterxml.jackson.core:jackson-core 2.15.0-2.18.5 or 2.19.0-2.21.0, or tools.jackson.core:jackson-core 3.0.0-3.0.x. Publicly available exploit code exists (PoC JUnit test published in GHSA-72hv-8253-57qq); the vulnerability is not listed in the CISA KEV catalog at time of analysis.
Memory exhaustion in jackson-core's non-blocking async parser allows remote unauthenticated attackers to exhaust JVM heap by streaming JSON integer digit sequences in small chunks without ever sending a terminator byte. The prior fix for GHSA-72hv-8253-57qq (CVE-2026-18401) failed to insert a `validateIntegerLength()` call on the `NOT_AVAILABLE` return path inside `MINOR_NUMBER_INTEGER_DIGITS`, allowing the internal `TextBuffer` accumulator to grow bounded only by `maxStringLength` (20 MiB default) rather than `maxNumberLength` (1000 chars default) - a ~20,000x amplification yielding approximately 40 MiB of heap pressure per connection due to Java's 2-byte char representation. Reactive frameworks that feed inbound HTTP or gRPC bytes incrementally to the async parser - Spring WebFlux/Reactor, Quarkus, Helidon, and Vert.x - are the primary risk surface; no public exploit identified at time of analysis.
Uncontrolled-recursion denial of service in FasterXML jackson-core 3.0.0 through 3.0.x lets a remote attacker crash JSON-processing services by submitting a deeply nested JSON document. The UTF8DataInputJsonParser (DataInput sources) and ReaderBasedJsonParser fail to enforce the StreamReadConstraints maxNestingDepth limit (default 500), so excessive nesting drives a StackOverflowError. No public exploit identified at time of analysis and EPSS is low (0.06%), but the bug is trivially triggerable against any service that parses untrusted JSON with these parsers; fixed in 3.1.0.
Denial of service in FasterXML jackson-core's non-blocking (async) JSON parser allows unauthenticated network attackers to exhaust JVM heap and CPU by submitting JSON containing arbitrarily long number tokens that bypass the maxNumberLength constraint. Affected deployments are those using the async parser API - particularly reactive frameworks such as Spring WebFlux - running com.fasterxml.jackson.core:jackson-core 2.15.0-2.18.5 or 2.19.0-2.21.0, or tools.jackson.core:jackson-core 3.0.0-3.0.x. Publicly available exploit code exists (PoC JUnit test published in GHSA-72hv-8253-57qq); the vulnerability is not listed in the CISA KEV catalog at time of analysis.