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 2.22.3, 2.21.7 or 2.18.11 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 2.22.3, 2.21.7 or 2.18.11 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 2.21.4 or 2.18.8 by release line, 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 2.21.1 or 2.18.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. Patches jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. Workarounds Users should avoid parsing input files from untrusted sources.
Recommended action: Upgrade to 2.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw in Jackson-core's JsonLocation.appendSourceDesc method allows up to 500 bytes of unintended memory content to be included in exception messages. When parsing JSON from a byte array with an offset and length, the exception message incorrectly reads from the beginning of the array instead of the logical payload start. This results in possible information disclosure in systems using pooled or reused buffers, like Netty or Vert.x. Details The vulnerability affects the creation of exception messages like: When JsonFactory.createParser(byte[] data, int offset, int len) is used, and an error occurs while parsing, the exception message should include a snippet from the specified logical payload. However, the method appendSourceDesc ignores the offset, and always starts reading from index 0. If the buffer contains residual sensitive data from a previous request, such as credentials or document contents, that data may be exposed if the exception is propagated to the client. The…
Recommended action: Upgrade to 2.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.