Jackson Core
Monthly
Heap exhaustion denial of service in FasterXML jackson-core 2.16.0 and later allows an unauthenticated remote attacker to force allocation of roughly 100 MB or more per oversized JSON property name whenever untrusted JSON is parsed from a character-based source (String, Reader, or char[]), which is the normal path for a request body already read into a String. Because the maxNameLength bound (default 50,000 characters, ~100 KB) is only validated after the entire name has been buffered, the much larger maxStringLength bound (default 100,000,000 characters, roughly 200 MB with segment bookkeeping overhead) governs first, and repeating this across concurrent requests can exhaust the heap and crash the process. The impact is availability-only (CVSS 3.1 7.5, AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:H); no public exploit code or confirmed active exploitation was identified at time of analysis, and a vendor patch is available.
Denial of service in FasterXML jackson-core 2.8.0 and later: an unauthenticated remote attacker who can supply a malformed JSON token to a parser created via JsonFactory.createParser(DataInput) causes UTF8DataInputJsonParser._reportInvalidToken() to accumulate the entire offending token into an exception message without ever applying ErrorReportConfiguration.getMaxErrorTokenLength(). The reporter measured a 20,000,109-character exception message from a 20-million-character malformed token (versus 367 characters for identical input on the InputStream path), and because the StringBuilder also incurs byte-to-char expansion and internal array doubling, scaling the payload can exhaust heap and trigger a JVM-wide OutOfMemoryError. Only the DataInput parser path is reachable, impact is availability-only, and no public exploit identified at time of analysis; the 7.5 base score captures the theoretical worst case rather than the narrow real-world reachability.
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.
Heap exhaustion denial of service in FasterXML jackson-core 2.16.0 and later allows an unauthenticated remote attacker to force allocation of roughly 100 MB or more per oversized JSON property name whenever untrusted JSON is parsed from a character-based source (String, Reader, or char[]), which is the normal path for a request body already read into a String. Because the maxNameLength bound (default 50,000 characters, ~100 KB) is only validated after the entire name has been buffered, the much larger maxStringLength bound (default 100,000,000 characters, roughly 200 MB with segment bookkeeping overhead) governs first, and repeating this across concurrent requests can exhaust the heap and crash the process. The impact is availability-only (CVSS 3.1 7.5, AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:H); no public exploit code or confirmed active exploitation was identified at time of analysis, and a vendor patch is available.
Denial of service in FasterXML jackson-core 2.8.0 and later: an unauthenticated remote attacker who can supply a malformed JSON token to a parser created via JsonFactory.createParser(DataInput) causes UTF8DataInputJsonParser._reportInvalidToken() to accumulate the entire offending token into an exception message without ever applying ErrorReportConfiguration.getMaxErrorTokenLength(). The reporter measured a 20,000,109-character exception message from a 20-million-character malformed token (versus 367 characters for identical input on the InputStream path), and because the StringBuilder also incurs byte-to-char expansion and internal array doubling, scaling the payload can exhaust heap and trigger a JVM-wide OutOfMemoryError. Only the DataInput parser path is reachable, impact is availability-only, and no public exploit identified at time of analysis; the 7.5 base score captures the theoretical worst case rather than the narrow real-world reachability.
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.