jackson-check

Инструмент самопроверки по 26 рекомендациям по безопасности для jackson-databind + jackson-core. Единственный jar без зависимостей, без подключения к сети.

Он отвечает на три вопроса, на которые Dependabot ответить не может:

0. Попал ли я под ту уязвимость, которую Dependabot не учёл? — по состоянию на 2026-10-05 остаётся только одна запись CVE-2026-68498 в jackson-core (см. раздел «v0.3.0»).
1. Под сколько из этих 26 я реально попадаю? — сканирует ваш исходный код на наличие условий срабатывания (@JsonView / полиморфные типы / сопоставление без учёта регистра……), снижая шум от «установлена уязвимая версия» до «действительно задействована эта функция».
2. До какой версии мне в итоге обновиться? — исправленные версии, указанные в разных advisory, не согласуются между собой, ответ можно получить только путём пересечения по каждой записи.

java -jar jackson-check.jar ./target ./src

🔴 v0.4.0 (2026-10-05): версия «исправлено всё за один раз» снова изменилась — 2.18.11 / 2.21.7 / 2.22.3 / 3.1.7 / 3.2.3

30.09 и 01.10 FasterXML выпустил ещё 4 high-уязвимости (все 7.5, все — отказ в обслуживании):

Номер	Координата	Тема	Условие срабатывания
CVE-2026-91776	jackson-databind	Каждый неизвестный type id оставляет запись в кэше на всё время жизни процесса, память только растёт	@JsonTypeInfo(use = Id.NAME, defaultImpl = …) + атакующий может управлять type id + mapper долго переиспользуется
CVE-2026-91777	jackson-databind	При доопределении forward-ссылок в обратном порядке число сравнений порядка N²/2 (N=2000 → 2 003 000)	Десериализация недоверенного JSON в коллекцию или Map с @JsonIdentityInfo
CVE-2026-89425	jackson-core	Некорректный токен целиком вставляется в текст исключения, не ограничиваясь maxErrorTokenLength	Только путь createParser(DataInput); в бюллетене указано, что настроек для смягчения нет
CVE-2026-89407	jackson-core	Квадратичный бэктрекинг регулярного выражения в NumberInput.looksLikeValidNumber() (на 160 тыс. символов замерено 74,4 секунды)	Привязка строки из JSON к числовому полю (поведение databind по умолчанию); этот путь ограничен maxStringLength (по умолчанию 20 млн), а не maxNumberLength (по умолчанию 1000)

Исправленные версии для обеих координат совпадают: 2.18.11 / 2.21.7 / 2.22.3 / 3.1.7 / 3.2.3 (все доступны в Central; 89407 в ветке 3.2 исправлена в 3.2.2, для 89425 нужна 3.2.3, берём большую).

Поэтому версии 2.18.10 / 2.21.6 / 2.22.2 / 3.1.6 / 3.2.2, которые выводили v0.2.0 / v0.3.0, с 30.09 уже недостаточны. Jar-файлы старых версий об этом не узнают — пересканируйте с v0.4.0.

⚠️ Эти четыре не являются слепой зоной Dependabot: в день выпуска они попали в глобальную базу уязвимостей GitHub, и Dependabot выдаст по ним обычные предупреждения. v0.4.0 включает их лишь для того, чтобы ответ на вопрос «до какой версии обновляться» оставался верным.

🔴 Заодно исправление одного утверждения из v0.2.0: в разделе «v0.2.0» ниже написано, что «те 4 не включены в глобальную базу уязвимостей GitHub, Dependabot их не сообщит» — это было верно по состоянию на 14.09, но с 2026-09-28 уже неверно — все четыре внесены в глобальную базу (повторный запуск ASSERT2 в gen_rules.py 05.10: слепая зона на стороне databind 4 → 0). Сейчас единственное, что по-прежнему не находится, — это CVE-2026-68498 в jackson-core.

🔴 v0.3.0 (2026-09-21): jackson-core — это другая координата, сканирование databind её не находит

Вся таблица проверок v0.2.x содержала единственный artifactId — jackson-databind. Поэтому 7 бюллетеней, выпущенных FasterXML в репозитории jackson-core, этот инструмент не находил ни одного — и при этом не выдавал никакой ошибки, просто молча пропускал все jackson-core-*.jar. «Не найдено при сканировании» и «вы в безопасности» в отчёте выглядят одинаково.

v0.3.0 меняет гранулярность проверки с advisory × groupId × диапазон на advisory × groupId × artifactId × диапазон, и проверка, пересечение и «эта координата не найдена при сканировании» — всё теперь ключуется по полной координате.

Самое важное — CVE-2026-68498 (high 7.5, 2026-09-12): StreamReadConstraints.maxNameLength (по умолчанию 50 тыс. символов) не действует на пути символьного ввода. ReaderBasedJsonParser при накоплении имени свойства обращается к лимиту длины строки (по умолчанию 100 млн, примерно в 2000 раз больше), а настоящая проверка name выполняется только после того, как весь key просканирован, — к тому моменту уже выделено около 200 МБ. Достаточно одного сверхдлинного JSON key, срабатывает при конфигурации по умолчанию.

• Затронуты: >= 2.16.0, <= 2.18.9 → 2.18.10 · >= 2.19.0, <= 2.21.5 → 2.21.6 · >= 2.22.0, <= 2.22.1 → 2.22.2 · 3.x (tools.jackson.core) <= 3.1.5 → 3.1.6 · <= 3.2.1 → 3.2.2
• Байтовый ввод не затронут: UTF8StreamJsonParser перепроверяет при каждом расширении буфера. Разбор из byte[] / InputStream не подвержен; подвержен только разбор из String / Reader / char[].
• Проверено по байткоду в обе стороны: вызов validateNameLength присутствует только в исправленном ReaderBasedJsonParser, в уязвимых версиях его нет (воспроизведено на всех трёх ветках: 2.18.9→2.18.10 · 2.21.5→2.21.6 · 3.1.5→3.1.6).

⚠️ Границы возможностей инструмента, написано здесь, чтобы избежать неверного понимания: этот инструмент определяет версию jar, но не может определить способ вашего вызова — readValue(someStringVariable, …) — это самый распространённый вариант записи, текстовый анализ не может определить, является ли эта переменная String или byte[]. Поэтому «условие срабатывания не найдено» не означает, что вы не затронуты; в отчёте это так и печатается.

🔴 Не читайте это как «Dependabot полностью слеп к jackson-core»: из тех 7 записей jackson-core только CVE-2026-68498 одна не находится в глобальной базе уязвимостей GitHub, остальные 6 уже включены, и Dependabot нормально выдаёт предупреждения. Эта запись проверяется заново при каждом перезапуске ASSERT-C2 в gen_rules.py, при изменении числа генерация отклоняется.

v0.2.0 (2026-09-14): 08-21 / 09-01 выпущены ещё 4 записи, на тот момент не включённые в глобальную базу уязвимостей GitHub

🔴 Этот раздел — запись от 09-14, два места уже устарели (см. выше «v0.4.0»): ① эти 4 записи были включены в глобальную базу 2026-09-28, Dependabot теперь их сообщает; ② версии «исправить за один раз» уже не 2.18.10 / 2.21.6 / 3.1.6. Исходный текст сохранён, не удалён.

FasterXML опубликовал 4 новые записи на странице Security своего репозитория:

Номер	Уровень	Тема	Исправленная версия
CVE-2026-68497	high 7.5	При привязке строк к javax.xml.datatype.Duration / XMLGregorianCalendar длина числа не ограничена → CPU DoS (достаточно маппера по умолчанию)	2.18.10 / 2.21.6 / 2.22.2 / 3.1.6 / 3.2.2
CVE-2026-19032	medium 5.3	Десериализация java.nio.file.Path не ограничивает схему URI, что позволяет задействовать любой зарегистрированный FileSystemProvider	То же
CVE-2026-83557	medium 5.6	В списке запретов по умолчанию PolymorphicTypeValidator пропущен Comparable	То же
CVE-2026-77310	medium 5.3	CVE-2026-54514 исправлен не полностью: ветка InetAddress по-прежнему немедленно выполняет DNS-разрешение	2.18.9 / 2.21.5 / 2.22.1 / 3.1.5 / 3.2.1

Поэтапная проверка: