OCTOBER 10, 2026
Live Feed
Back to database
Case File

CVE-2026-89407

HIGH · CVSS 7.5 EPSS 0.55% Public Exploit

Source: NVD + CISA KEV + EPSS · Published 2026-09-22 · Last synced 2026-10-10

CyberRota Analysis

AI-Generated

The vulnerability affects the FasterXML Jackson library in Java, specifically the `NumberInput.looksLikeValidNumber()` method, which improperly handles "stringified numbers" due to inefficient regular expression patterns. This can lead to a denial-of-service condition, as an attacker can exploit the regex backtracking behavior to exhaust server resources by supplying excessively long JSON inputs. Organizations using Jackson versions 2.17.0 and above should prioritize patching this vulnerability to mitigate potential service disruptions.

Public Exploit Signal

A public exploit, PoC, GitHub repository or Metasploit reference was detected for this CVE.

Note: these links are listed for security research and verification purposes only.

CVE
CVE-2026-89407
Severity
HIGH
CVSS
7.5
EPSS
0.55%
Java

Original NVD 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.