NumberInput.looksLikeValidNumber() in jackson-core validates stringized numeric values using two regular expressions that contain adjacent optional and required quantifiers. When a string does not match, Java’s regex engine backtracks through every possible split point of the digit run, causing quadratic runtime cost in the length of the token. This can be exploited by an attacker who sends a very long string that is coerced to a numeric type during JSON deserialization, consuming significant CPU time and exhausting a server’s request‑handling threads. The weakness is classified as CWE‑1333 (Regular Expression Denial of Service) and CWE‑400 (Uncontrolled Resource Consumption).

Affected systems include any application that incorporates FasterXML jackson‑core versions from 2.17.0 up through the 2.20.x and 3.0.x lines that have not received the fix. The vulnerability is present in the two PATTERN_FLOAT regular expressions used by NumberInput.looksLikeValidNumber(); earlier releases prior to 2.17.0 are unaffected. Because the default StreamReadConstraints.maxStringLength is 20 000 000 characters, there is no size limitation imposed before the string reaches the regex, allowing malicious payloads of arbitrarily large length.

The CVSS base score is 7.5, indicating high severity. The EPSS score is not available, so the likelihood of exploitation cannot be quantified, and the vulnerability is not listed in the CISA KEV catalog, suggesting no known public exploits at this time. The likely attack vector is an application that deserializes JSON containing large numeric strings and coerces them to a numeric target type via jackson-databind. Attackers could send dozens of such payloads concurrently to tie up server threads and cause a denial of service.