Один jar, ноль зависимостей времени выполнения, полностью офлайн, Java 17+.

Зачем это существует

1. Netty выпускает один номер версии, но у каждого модуля свой «исправлено в»

Каждый модуль Netty выпускается под одним и тем же номером версии, поэтому обновление выглядит как одно решение. Но это не так. На ветке 4.1 версии исправлений для этих четырнадцати приходятся на 125 / 129 / 132 / 133 / 135 / 136 / 137 — семь разных значений. Следуйте любому одному бюллетеню, и вы всё ещё находитесь в зоне поражения остальных.

2. Если вы исправили CVE в HTTP/2, вы, скорее всего, всё ещё уязвимы здесь

netty-codec-http2 объявляет netty-codec-http как зависимость compile с <version>${project.version}</version> — эти две версии жёстко привязаны друг к другу.

Поэтому если вы обновились до 4.1.136.Final, потому что именно эта версия закрывает семь CVE в netty-codec-http2, теперь у вас работает и netty-codec-http 4.1.136.Final — а CVE-2026-59903 покрывает <= 4.1.136.Final. Вам нужна 4.1.137.Final. Та же история на ветке 4.2: ответ для HTTP/2 — 4.2.16.Final, этой стороне нужна 4.2.17.Final.

Это не утверждение, что рекомендация по HTTP/2 была неверной — она отвечала за другой модуль. Это утверждение, что «один номер версии» скрывает тот факт, что вы отвечали только за один модуль.

3. Границы записаны непоследовательно, и одна версия от этого меняет статус

В этих четырнадцати бюллетенях верхняя граница записана как <= 16 раз и < 12 раз. Одна и та же 4.1.136.Final поэтому безопасна для CVE-2026-56746 (< 4.1.136.Final) и уязвима для CVE-2026-59903 (<= 4.1.136.Final).

Нормализация оператора в любую сторону даёт неверный ответ — одно направление завышает, другое занижает, а занижение — это дорогостоящая ошибка для такого инструмента. Таблица правил сохраняет каждый оператор ровно так, как его записал бюллетень, а проверка в tools/gen_rules.py ломает сборку, если этот пограничный случай перестанет вести себя так.

И он не сканирует pom.xml — намеренно

Если вы используете Spring WebFlux, netty-codec-http приходит через

artifactId никогда не появляется в вашем pom.xml. Проверка на основе pom отвечает «я это не использую», что неверно. Этот инструмент читает jar-файлы, которые реально поставляются.

Использование

Коды выхода: 0 = не уязвим · 1 = уязвим · 2 = невозможно оценить.

🔴 2 намеренно не равен 0. «Ничего не найдено» и «чисто» не должны выглядеть одинаково для скрипта. Файл, который не является читаемым zip, сообщается как ошибка чтения и никогда молча не трактуется как «netty здесь нет».

Что он не сообщает

• Только эти 14 CVE, только netty-codec-http. У других модулей Netty есть свои CVE; чистый результат здесь ничего о них не говорит. Если у вас также есть netty-codec-http2, инструмент сообщает об этом и указывает на межмодульную проблему выше, но не оценивает этот модуль.
• Серьёзность сообщается как опубликована. Два из четырнадцати не имеют оценки CVSS, и один — low; они выводятся как есть, а не сводятся в пугающий итог.
• Каждый из этих бюллетеней имеет статус reviewed с полными метаданными пакета, поэтому Dependabot и подобные инструменты действительно предупреждают о них. Этот инструмент — не «сканер этого не видит» — он про то, что «предупреждение сообщает вам номер версии для каждого бюллетеня, а вам всё равно нужно выяснить, какая единственная версия это прекращает».

Как строится таблица правил

src/main/java/dev/mikko/nettyhttpcheck/RuleTable.java — генерируемый, никогда не редактируется вручную:

Семь проверок должны пройти, иначе ничего не записывается — среди них: каждый бюллетень всё ещё reviewed; обе ветки версий присутствуют для каждого; вычисленное пересечение всё ещё 4.1.137.Final / 4.2.17.Final; эти версии реально доступны для загрузки из Maven Central (с версией-маяком, которая должна давать 404, чтобы сломанный зонд не мог пройти молча); пограничный случай из §3 всё ещё переключается; и ответ по HTTP/2 из §2 всё ещё оставляет дыру на этой стороне.

Сквозные проверки на реальных jar-файлах находятся в tools/e2e_real_jars.py — они скачивают настоящие jar-файлы с Maven Central, а не фикстуры, потому что «работает на собранном вручную zip, падает на настоящем jar» — это реальный сценарий отказа.

Лицензия

MIT