Hi,

The following vulnerability was published for jackson-core.

CVE-2026-89425[0]:
| 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.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-89425
https://www.cve.org/CVERecord?id=CVE-2026-89425
[1] https://github.com/FasterXML/jackson-core/security/advisories/GHSA-7hhh-6rmp-j9qf
[2] https://github.com/FasterXML/jackson-core/pull/1698

Regards,
Salvatore

Hi,

I reassigned #1135411 to jackson-core: it comes from CVE-2025-52999.patch
(https://security-tracker.debian.org/tracker/CVE-2025-52999), which
backports the 2.15 number parsing but not the inLongRange() check from
https://github.com/FasterXML/jackson-core/pull/865. Since then every
integer with 19 digits, Long.MIN_VALUE and Long.MAX_VALUE included, fails
with "Numeric value (...) out of range of long". The build skips the
tests, so nobody noticed.

While fixing it I found that the same backport has two more gaps:

- Limits set on a JsonFactory are ignored; the parsers always use the
  defaults.
- The async parser does not enforce maxNumberLength. That is
  CVE-2026-18401 and its follow-up CVE-2026-68494
  (https://security-tracker.debian.org/tracker/CVE-2026-18401,
https://security-tracker.debian.org/tracker/CVE-2026-68494). The
  tracker marks jackson-core not affected because upstream 2.14.1 has no
  number length limit, but Debian's 2.14.1-2 does, from the
  CVE-2025-52999 backport, and its async parser accepts over-long
  numbers. I checked that in unstable.

And #1148826 (CVE-2026-89425,
https://security-tracker.debian.org/tracker/CVE-2026-89425) affects
2.14.1 as well: the DataInput parser reads the whole invalid token into
the error message, so a large one runs out of memory.

One merge request fixes all of it, each as its own patch backported from
upstream: https://salsa.debian.org/java-team/jackson-core/-/merge_requests/8
With it and the jackson-databind fix for #1139511, jackson-modules-java8
builds again and its tests pass.

trixie (2.14.1-2~deb13u1) and bookworm (2.14.1-2~deb12u1) carry the same
patch, so they should have the same problems at run time (I tested
unstable only). Copying the security team for that.

Thanks,
Juan