Описание
jackson-core: ReDoS: quadratic backtracking in NumberInput.PATTERN_FLOAT via looksLikeValidNumber()
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(PATTERN_FLOATline ~41-42,PATTERN_FLOAT_TRAILING_DOTline ~51, entry pointlooksLikeValidNumber()lines ~646-656)
Technical Analysis
PATTERN_FLOAT 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 the engine must explore every possible split point between the
[0-9]* and [0-9]+ groups before concluding failure — the classic quadratic-backtracking
shape. looksLikeValidNumber() compounds the cost by running a second full-string regex
(PATTERN_FLOAT_TRAILING_DOT) whenever the first fails, roughly doubling the constant factor
without changing the asymptotic class.
Critically, the length gate that applies to this specific path is
StreamReadConstraints.maxStringLength (default 20,000,000), not maxNumberLength
(default 1,000) — the length ceiling the library uses everywhere else for numeric content.
This means inputs up to four orders of magnitude larger than the library's own numeric-length
policy reach this quadratic regex unmodified.
Reproduction Procedure
Same clone/build steps as jackson-core_1_...md. Then:
Full PoC Source (poc/PoC8_NumberInputReDoS.java)
Captured Evidence (actual run output)
This is an unusually clean empirical result: five consecutive doublings each produced a ratio between 3.78x and 4.14x — matching the theoretical O(n²) prediction (ratio = 4.0x) to within 5% at every single measurement, leaving essentially no ambiguity about the complexity class. Extrapolating this measured curve, a ~1MB string (well within common request body limits) would take on the order of hours for a single call.
Impact
Any application that coerces a String-typed JSON field to a number (default jackson-databind
behavior) is exposed: an attacker who can submit a large numeric-looking string (up to
maxStringLength's default of 20,000,000 characters — far larger than needed given the
measured curve) can pin a request-handling thread for an extended period with a single request.
Because the cost scales quadratically, a handful of concurrent moderately-sized requests
(tens to low hundreds of KB each) is sufficient to exhaust a typical web server's worker thread
pool, denying service to all users.
Remediation
- Rewrite
PATTERN_FLOATwithout quantifier ambiguity using possessive quantifiers, e.g.[+-]?(?:[0-9]++(?:\.[0-9]*+)?|\.[0-9]++)(?:[eE][+-]?[0-9]++)?, which also folds in the trailing-dot case and removes the need for a second full-string scan. - Better: replace the regex entirely with a single-pass hand-written character scan — the same
file already contains exactly this pattern for
parseInt, so the library has both the precedent and the code style available. - Apply an independent length limit (
maxNumberLength, not the much largermaxStringLength) before callinglooksLikeValidNumber(), closing the four-orders-of- magnitude gap between the two constraints for this specific code path. - Operationally, until fixed: tighten
StreamReadConstraints.maxStringLengthwell below its default, and set wall-clock timeouts on parse/coercion operations.
Ссылки
- https://github.com/FasterXML/jackson-core/security/advisories/GHSA-p6pp-m3f8-5c89
- https://nvd.nist.gov/vuln/detail/CVE-2026-89407
- https://github.com/FasterXML/jackson-core/issues/1649
- https://github.com/FasterXML/jackson-core/pull/1650
- https://github.com/FasterXML/jackson-core/pull/1701
- https://github.com/FasterXML/jackson-core/commit/731e794f62623aa0d86ced52490166be903fbb1d
- https://github.com/FasterXML/jackson-core/commit/e7acd64cc99bd346704423dc2bfea1ab0a08ddff
Пакеты
com.fasterxml.jackson.core:jackson-core
>= 2.17.0, <= 2.18.10
2.18.11
com.fasterxml.jackson.core:jackson-core
>= 2.19.0, <= 2.21.6
2.21.7
com.fasterxml.jackson.core:jackson-core
>= 2.22.0, <= 2.22.2
2.22.3
tools.jackson.core:jackson-core
>= 3.0.0, <= 3.1.6
3.1.7
tools.jackson.core:jackson-core
>= 3.2.0, <= 3.2.1
3.2.2
Связанные уязвимости
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...
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...
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 reach
NumberInput.looksLikeValidNumber() in FasterXML jackson-core pre-valid ...