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
