Regular Expression Denial of Service (ReDoS)com.fasterxml.jackson.core:jackson-core is a Core Jackson abstractions, basic JSON streaming API implementation
Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) in the PATTERN_FLOAT regex of NumberInput, reached through looksLikeValidNumber(), where adjacent quantifiers over the same character class ([0-9]*, then an optional [.], then [0-9]+) carry no possessive quantifiers or atomic grouping, so the engine explores every split point between digit groups on non-matching input. An attacker can pin a request-handling thread and exhaust the worker pool with concurrent requests by supplying a long numeric-looking string that fails to match, since match cost is quadratic in input length, with 160,000 characters costing 74.4 seconds in a single call. This requires the application to reach looksLikeValidNumber() with attacker-controlled strings, which is the default path when jackson-databind coerces a String field to a number, and the input is bounded only by StreamReadConstraints.maxStringLength at 20,000,000 rather than by maxNumberLength at 1,000.
How to fix Regular Expression Denial of Service (ReDoS)? Upgrade com.fasterxml.jackson.core:jackson-core to version 2.18.11, 2.21.7, 2.22.3 or higher.
| [2.17.1,2.18.11)[2.19.0,2.21.7)[2.22.0,2.22.3) |
Allocation of Resources Without Limits or Throttlingcom.fasterxml.jackson.core:jackson-core is a Core Jackson abstractions, basic JSON streaming API implementation
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the _reportInvalidToken(int, String, String) method of UTF8DataInputJsonParser, which accumulates invalid token characters into a StringBuilder with no check against ErrorReportConfiguration.getMaxErrorTokenLength(), unlike UTF8StreamJsonParser, ReaderBasedJsonParser, and NonBlockingUtf8JsonParserBase, which enforce the 256-character default. An attacker can exhaust the JVM heap by submitting a sufficiently long malformed token, since the whole token is copied into the exception message, where a 20-million-character token produces a 20,000,109-character message against 367 characters on the bounded path. This requires the application to create its parser through JsonFactory.createParser(DataInput), and no configuration constrains the path, since maxDocumentLength does not apply to DataInput sources and maxStringLength does not cover it.
How to fix Allocation of Resources Without Limits or Throttling? Upgrade com.fasterxml.jackson.core:jackson-core to version 2.18.11, 2.21.7, 2.22.3 or higher.
| [2.8.0,2.18.11)[2.19.0,2.21.7)[2.22.0,2.22.3) |
