tomcat-check

Определяет реально установленную версию Tomcat и для каждой CVE 2026 года приводит сразу две системы оценок и условия срабатывания.

Один jar без зависимостей, работает офлайн, не выходит в сеть и ничего не отправляет.

Что он решает

Во-первых, версии встроенного Tomcat в проектах Spring Boot нет в вашем pom.

Она управляется свойством tomcat.version из spring-boot-starter-parent, а в pom вы видите только spring-boot-starter-web. Поэтому этот инструмент сканирует артефакты сборки (jar / fat jar / каталог установки), а не читает pom.

Во-вторых, некоторые записи не попадают в предупреждения Dependabot.

В 2026 году Tomcat опубликовал 29 CVE, и часть из них по двум механизмам не появляется в предупреждениях для проектов Spring Boot:

Практический результат: для приложения Spring Boot со встроенным Tomcat 9.0.118, у которого панель Dependabot полностью зелёная, этот инструмент сообщит о 4 совпадениях, и одно из них эксплуатируется при конфигурации по умолчанию.

В-третьих, у двух систем оценок разные критерии, а вы видите только одну из них.

Из 29 записей у 17 расхождение между двумя системами оценок составляет 2 уровня и более; самый крайний случай — CVE-2026-41293: официально Low, на GitHub critical, CVSS 9.8.

Это не чья-то ошибка. Две системы по определению измеряют разные вещи. Но чтобы решить, «стоит ли обновляться прямо сейчас», вам нужно видеть их обе — а также то, включена ли у вас эта функция.

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

java -jar tomcat-check.jar <jar 或目录> ...

  --all     连「不适用」的条目也列出来
  --utf8    Windows 控制台中文乱码时加这个

# Spring Boot fat jar
java -jar tomcat-check.jar target/my-app.jar

# 独立安装的 Tomcat
java -jar tomcat-check.jar /opt/tomcat

# 整个依赖目录
java -jar tomcat-check.jar target/lib

Требуется Java 17+.

Что содержится в выводе

Для каждого совпадения вывод содержит: две системы оценок, условия срабатывания, оригинальный текст официального описания и то, появится ли эта запись в ваших предупреждениях Dependabot. В конце приводится целевая версия для обновления, которая покрывает все совпадения.

🔴 Читайте вывод так

• «Совпадение» = ваша версия попадает в официальный диапазон Affects, это не значит «уже эксплуатируется» и не значит «обязательно эксплуатируемо». Из 29 записей лишь немногие эксплуатируются при конфигурации по умолчанию, остальные требуют, чтобы вы явно включили какую-то функцию (RewriteValve, DIGEST-аутентификация, AJP, WebDAV, связь в кластере…). Сверяйтесь с условиями срабатывания по каждой записи.
• «Dependabot не предупредит» — это не значит, что GitHub не выполняет свою работу. unreviewed — это нормальное состояние процесса.
• Таблица соответствий покрывает только CVE, опубликованные в 2026 году. Отсутствие совпадений не означает, что с вашей версией всё в порядке.
• Инструмент не решает за вас, обновляться ли, — он даёт три вещи, необходимые для этого решения: какая у вас установлена версия, как её оценивает официальный источник и каковы условия срабатывания.

Откуда взялась таблица соответствий

tools/gen_rules.py генерирует CveTable.java из двух первоисточников — ни одна строка не переписана вручную:

• https://tomcat.apache.org/security-{9,10,11}.html — официальные оценки, заголовки, оригинальные описания, затронутые диапазоны версий
• GitHub Advisory API — оценки GitHub, CVSS, type, затронутые координаты Maven

Процесс генерации включает 7 утверждений (assertions): если хоть одно не выполняется, процесс останавливается и файл не записывается. Три из них стоит рассмотреть отдельно:

• ASSERT7 (полнота разбора): записи пересчитываются вторым, независимым регулярным выражением — оба набора должны полностью совпасть. Поводом стал один очень коварный тип несоответствия: в некоторых заголовках на официальной странице встроена ссылка на другую CVE: <strong>Moderate: The fix for <a>CVE-2025-66614</a> was incomplete</strong> <a>CVE-2026-32990</a>. Поиск «первой CVE» во всём блоке подхватит тот старый номер, что встроен в заголовок, и последствие — не «потеряна одна запись», а подмена: одна CVE получает заголовок и описание другой, при этом генерация, тесты и проверка на реальных артефактах все проходят как обычно.
• ASSERT3 (направление сопоставления): на официальной странице строка Affects: стоит непосредственно перед заголовком следующей CVE, и её очень легко сопоставить не с той записью — если ошибиться, получится таблица, которая «выглядит совершенно нормальной, но целиком сдвинута на одну позицию». Делается перекрёстная проверка с first_patched_version из GitHub — во время разработки это действительно помогло поймать одно смещение.
• ASSERT6 (основание исключения): скачиваются реальные jar всех трёх линеек — 9.0 / 10.1 / 11.0, и для каждой исключённой записи (компоненты кластера, FFM-коннектор, примеры приложений) подтверждается, что код действительно отсутствует в tomcat-embed-*. Основанием исключения должен быть фактический замер, а не «я помню».

Перегенерировать:

python tools/gen_rules.py

Сборка

mvn clean package     # → target/tomcat-check.jar

34 теста. Ноль зависимостей в рантайме, JUnit только на этапе тестирования.

Лицензия

MIT