CVE-2026-89407 in jackson-core
Summary
by MITRE • 09/22/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability resides within the FasterXML jackson-core library, specifically in the NumberInput.looksLikeValidNumber() method introduced in version 2.17.0 and refined in 2.17.2. This method is responsible for pre-validating stringified numbers before they are deserialized into numeric types such as BigDecimal, BigInteger, Double, or Float via jackson-databind's default coercion mechanisms. The core technical flaw stems from the design of two regular expressions used for validation: PATTERN_FLOAT and PATTERN_FLOAT_TRAILING_DOT. These patterns utilize adjacent quantifiers over the same character class, specifically combining an optional sequence of digits [0-9]* with a required sequence of digits [0-9]+ separated by an optional decimal point. This structure creates catastrophic backtracking scenarios within Java's regular expression engine when processing inputs that ultimately fail to match the pattern but contain long sequences of digits.
When an attacker supplies JSON containing a malformed numeric string, such as one ending in multiple trailing dots or lacking proper exponential notation after a long digit sequence, the regex engine attempts every possible split point between the optional and required digit groups. This results in computational complexity that grows quadratically with the input length, denoted as O(n^2). The impact is severe because StreamReadConstraints.maxStringLength defaults to twenty million characters, providing no effective bound on the size of the string before it reaches the vulnerable regex logic. Consequently, a single request containing a moderately large malformed number string can consume significant CPU resources for an extended period. Testing has demonstrated that a 160,000-character string can take approximately seventy-four seconds to process in a single call.
From an operational perspective, this vulnerability enables Denial of Service attacks against applications relying on Jackson for JSON processing. An attacker does not need high privileges or complex exploits; they simply need the ability to submit JSON payloads that are deserialized into numeric target types. By sending a small number of concurrent requests with these crafted inputs, it is possible to exhaust the server's request-handling thread pool, rendering the service unavailable to legitimate users. This aligns with CWE-400 (Uncontrolled Resource Consumption) and maps to ATT&CK technique T1496 (Resource Hijacking), where an adversary uses resources in a way that degrades or denies availability of those resources for other processes or services.
The vulnerability affects versions 2.17.0 through the latest releases prior to the fix, while earlier versions such as 2.16.x and below are not impacted because the vulnerable method did not exist in their codebase. The recommended mitigation is to upgrade jackson-core to a version that includes the patch replacing the regular expressions with a hand-rolled single-pass scan algorithm. This approach eliminates the backtracking issue entirely by validating numeric formats through direct character inspection rather than regex matching, ensuring linear time complexity O(n) regardless of input length. Organizations should also consider implementing strict input validation and rate limiting on JSON endpoints to further mitigate potential abuse vectors until patches are applied.