Описание
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.
A flaw was found in jackson-core. An attacker can supply specially crafted JSON that, when deserialized into a numeric target type, triggers a Regular expression Denial of Service (ReDoS) vulnerability. This occurs due to quadratic backtracking in the NumberInput.looksLikeValidNumber() method's PATTERN_FLOAT regular expression. A small number of concurrent requests with a long input string can exhaust a server's request-handling thread pool, leading to a Denial of Service (DoS).
Отчет
This vulnerability is rated as Moderate impact because while remote actors can induce CPU starvation to trigger a denial of service, the issue affects availability only without granting unauthorized access or data tampering capabilities. In Red Hat environments, exposure depends on services deserializing untrusted JSON payloads into numeric Java object types where default string coercion occurs. Older releases packaging jackson-core versions prior to 2.17.0 do not include the vulnerable pattern matching logic and are unaffected.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Exploit Intelligence | exploit-intelligence/agent-client-rhel9 | Affected | ||
| OpenShift Developer Tools and Services | jenkins | Affected | ||
| OpenShift Developer Tools and Services | jenkins-2-plugins | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-ekb-dispatcher-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-ekb-receiver-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-ddb-streams-source-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-s3-sink-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-s3-source-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-sns-sink-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-sqs-sink-rhel9 | Affected |
Показывать по
Ссылки на источники
Дополнительная информация
Статус:
EPSS
5.9 Medium
CVSS3
Связанные уязвимости
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 reach
NumberInput.looksLikeValidNumber() in FasterXML jackson-core pre-valid ...
jackson-core: ReDoS: quadratic backtracking in NumberInput.PATTERN_FLOAT via looksLikeValidNumber()
EPSS
5.9 Medium
CVSS3