Skip to main content
Components
Vulnerabilities
Security Events
Pricing
MCP
API
Docs
Sign up
Login
Find vulnerabilities. Fix fast with AI.
Search components by package, version, or CVE to get started.
com.fasterxml.jackson.core/jackson-core 2.… | Sonatype Guide
Get full component data and automated fixes with Sonatype Guide.
Sign up for free
maven
com.fasterxml.jackson.core
jackson-core
2.22.2
jackson-core 2.22.2
com.fasterxml.jackson.core
Published
Aug 16, 2026
•
Policy
compliance
maven Registry
Developer Trust Score
Recommended Version:
x.y.z
Recommended upgrade that meets your policy.
Compare Versions
Overview
Overview
Versions
197
Versions
197
Vulnerabilities
2
Vulnerabilities
2
Dependencies
0
Dependencies
0
Severity
Critical
(0)
High
(2)
Medium
(0)
Low
(0)
CVSS Score
0.0
10.0
EPSS Score
0.0
1.0
Malware
KEV Status
Published
Filter
Sort: Published (Newest first)
7.5
CVE-2026-89425
UTF8DataInputJsonParser._reportInvalidToken() in FasterXML jackson-core builds the offending-token text for its error message by appending Java identifier characters to a StringBuilder in a loop that has no upper bound. Unlike the three sibling parser implementations, including UTF8StreamJsonParser, it never consults ErrorReportConfiguration.getMaxErrorTokenLength() (default 256). A malformed token supplied to a parser created through JsonFactory.createParser(DataInput) is therefore accumulated in full. No StreamReadConstraints setting mitigates this: maxDocumentLength cannot be applied to DataInput sources at all, and maxStringLength does not cover this path because the accumulation bypasses ReadConstrainedTextBuffer. The reporter measured a 20,000,109-character exception message from a 20-million-character malformed token on the DataInput path, against 367 characters for identical input on the InputStream path. Scaling the payload drives the StringBuilder, which also incurs byte-to-char expansion and internal array doubling, to many times the raw payload size and can trigger OutOfMemoryError for the whole JVM. UTF8DataInputJsonParser was introduced in 2.8.0 together with createParser(DataInput); releases before 2.8.0 do not contain the affected class.
affected
Severity
High
Published
Sep 23, 2026
7.5
CVE-2026-89407
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.
affected
Severity
High
Published
Sep 23, 2026
