Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Status FULLY REPRODUCED. A malformed token fed through createParser(DataInput) produced a 20,000,109-character exception message from a 20-million-character attacker payload, while the identical payload fed through createParser(InputStream) produced a correctly bounded 367-character message. Affected Component / Version - Package: com.fasterxml.jackson.core:jackson-core - Confirmed against: jackson-core-2.20.2 - Affected file: src/main/java/com/fasterxml/jackson/core/json/UTF8DataInputJsonParser.java (reportInvalidToken(int, String, String), lines ~2763-2780 in the 2.20.2 tree) Technical Analysis UTF8DataInputJsonParser.reportInvalidToken() builds the offending-token description for its exception message by appending identifier characters one at a time to a bare StringBuilder: There is no check against ErrorReportConfiguration.getMaxErrorTokenLength() (default 256) anywhere in this loop. By contrast, the sibling UTF8StreamJsonParser implementation of the same logic does enforce it:…
Recommended action: Upgrade to 3.2.3 or 3.1.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Status FULLY REPRODUCED with a clean, textbook empirical signature: measured runtime grew almost exactly 4x for every doubling of input size across five consecutive doublings (5,000 → 160,000 characters), confirming O(n²) behavior. A single 160,000-character string (smaller than a typical HTTP request body) took 74.4 seconds for one call to NumberInput.looksLikeValidNumber(). Affected Component / Version - Package: com.fasterxml.jackson.core:jackson-core - Confirmed against: jackson-core-2.20.2 - Affected file: src/main/java/com/fasterxml/jackson/core/io/NumberInput.java (PATTERNFLOAT line ~41-42, PATTERNFLOATTRAILINGDOT line ~51, entry point looksLikeValidNumber() lines ~646-656) Technical Analysis PATTERNFLOAT contains ambiguous, adjacent quantifiers over the identical character class: [0-9] (optional digits), an optional [.], then [0-9]+ (required digits). Java's backtracking Pattern/Matcher engine has no possessive quantifiers or atomic grouping here, so on a non-matching input…
Recommended action: Upgrade to 3.2.2 or 3.1.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix released in jackson-core 2.18.6 and 2.21.1 for GHSA-72hv-8253-57qq (Number Length Constraint Bypass in Async Parser, published 2026-02-28) is incomplete. The fix commit b0c428e6 (#1555) wired validateIntegerLength into a new setIntLength helper and called it at every place where the integer portion of a number is decided (terminator byte arrived, . / e/E seen, end-of-feed inside a fully-buffered value). It did not call it on the much more attacker-relevant path: "ran out of input while still inside MINORNUMBERINTEGERDIGITS, return NOTAVAILABLE to caller". As a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, can keep the parser inside MINORNUMBERINTEGERDIGITS indefinitely. textBuffer.expandCurrentSegment() grows on every chunk, and validateIntegerLength is never invoked. The accumulator is only gated by maxStringLength (20 MiB default) — a ~20,000x amplification of the documented…
Recommended action: Upgrade to 3.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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: -…
Recommended action: Upgrade to 3.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The UTF8DataInputJsonParser, which is used when parsing from a java.io.DataInput source, bypasses the maxNestingDepth constraint (default: 500) defined in StreamReadConstraints. A similar issue was found in ReaderBasedJsonParser. This allows a user to supply a JSON document with excessive nesting, which can cause a StackOverflowError when the structure is processed, leading to a Denial of Service (DoS). The related fix for com.fasterxml.jackson.core:jackson-core, CVE-2025-52999, was not fully applied to tools.jackson.core:jackson-core until the 3.1.0 release. It is recommended that 3.0.x users upgrade. Patches jackson-core contains a configurable limit for how deep Jackson will traverse in an input document. This check was missing in a few places in tools.jackson.core:jackson-core. The change is in https://github.com/FasterXML/jackson-core/pull/1554. jackson-core will throw a StreamConstraintsException if the limit is reached. jackson-databind also benefits from this change…
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The non-blocking (async) JSON parser in jackson-core bypasses the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS). The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy. Details The root cause is that the async parsing path in NonBlockingUtf8JsonParserBase (and related classes) does not call the methods responsible for number length validation. - The number parsing methods (e.g., finishNumberIntegralPart) accumulate digits into the TextBuffer without any length checks. - After parsing, they call valueComplete(), which finalizes the token but does not call resetInt() or resetFloat(). - The resetInt()/resetFloat() methods in ParserBase are where the…
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.