Description

NumberInput.looksLikeValidNumber() in FasterXML jackson-core pre-validates "stringified numbers" with two regular expressions: PATTERN_FLOAT ([+-]?[0-9]*[\.]?[0-9]+([eE][+-]?[0-9]+)?), present since 2.17.0, and PATTERN_FLOAT_TRAILING_DOT, added in 2.17.2. PATTERN_FLOAT places adjacent quantifiers over the same character class -- an optional [0-9]* run, an optional dot, then a required [0-9]+ run -- so input that ultimately fails to match forces Java's backtracking engine to retry every possible split point of the digit run.  Matching cost therefore grows with the square of the input length.  An attacker who can supply JSON that an application deserializes into a numeric target type reaches this method through jackson-databind's default String-to-number coercion (StdDeserializer and NumberDeserializers for BigDecimal, BigInteger, Double and Float).  Because StreamReadConstraints.maxStringLength defaults to 20,000,000 characters, no constraint bounds the input before it reaches the regex.  Testing by the reporter confirmed O(n^2) growth across five consecutive input-size doublings, with a single 160,000-character string consuming roughly 74 seconds in one call; a small number of concurrent requests of ordinary body size can therefore exhaust a server's request-handling thread pool.  The affected method does not exist before 2.17.0, so 2.16.x and earlier releases are not affected.  The fix replaces both regular expressions with a hand-rolled single-pass scan.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-22T15:17:21.053Z",
  "pubdate": "2026-09-22T15:17:21.053Z",
  "executiveSummary": "A Regular Expression Denial of Service (ReDoS) vulnerability exists in FasterXML jackson-core versions 2.17.0 through 2.17.1 (and potentially 2.17.2 regarding PATTERN_FLOAT_TRAILING_DOT).\nThe vulnerability resides in the NumberInput.looksLikeValidNumber() method, which utilizes inefficient regular expressions to pre-validate numeric strings.\nDue to the presence of nested quantifiers and overlapping character classes, the underlying Java regex engine experiences catastrophic backtracking when processing specifically crafted numeric inputs.\nThe default StreamReadConstraints.maxStringLength of 20,000,000 characters allows for sufficiently large payloads to induce significant CPU exhaustion.\nAn unauthenticated remote attacker can exploit this by submitting malformed JSON numeric strings that trigger the backtracking behavior.\nSuccessful exploitation forces the application to consume excessive CPU cycles for extended periods, leading to thread pool exhaustion and denial of service for legitimate users.\nThis vulnerability affects applications using jackson-databind that perform automatic String-to-number coercion for types such as BigDecimal, BigInteger, Double, and Float.",
  "technicalDetails": "The root cause of the vulnerability is the use of non-linear regular expressions within the NumberInput.looksLikeValidNumber() method in jackson-core. Specifically, the PATTERN_FLOAT regex ([+-]?[0-9]*[\\.]?[0-9]+([eE][+-]?[0-9]+)?) implements adjacent quantifiers over similar character classes. This structure creates a high degree of ambiguity for the NFA-based regex engine when the input string fails to match the full pattern.\nWhen a long, malformed string is provided, the regex engine attempts to find a match by exhaustively exploring all possible split points of the digit run. Because the patterns allow for optional sequences ([0-9]*) followed by required sequences ([0-9]+), the number of permutations the engine must evaluate grows quadratically, O(n^2), relative to the input length. Testing demonstrated that a single 160,000-character string could consume approximately 74 seconds of CPU time.\nThe attack flow begins when an attacker sends a crafted JSON payload containing a long, malformed numeric string to an endpoint that deserializes the input into a numeric target type (e.g., BigDecimal, BigInteger, Double, or Float). The jackson-databind library, using its default StdDeserializer and NumberDeserializers, invokes NumberInput.looksLikeValidNumber() as a pre-validation step during the coercion process. Since the default StreamReadConstraints.maxStringLength is set to 20,000,000 characters, the library does not reject the malicious string before it reaches the vulnerable regex logic.\nThe regex engine's performance degradation is deterministic and triggered by the input string's structure rather than successful parsing. By sending a small number of concurrent requests containing these large, ambiguous strings, an attacker can effectively pin down available CPU cores. This blocks the server from processing further requests, leading to thread pool starvation and a total denial of service for the target application. This issue is particularly critical in high-traffic environments where concurrent processing is standard. The vulnerable component, jackson-core, introduced these specific regex patterns in version 2.17.0, meaning earlier versions like 2.16.x are not impacted by this specific vector."
}