Эти 14 записей в трёх местах выглядят по-разному:

Единственное место, где всё это описано полностью — оригинальные записи на CVE.org, где Apache выступает как CNA — то есть тот слой, который меньше всего кто-либо открывает. Этот инструмент берёт информацию именно оттуда и сопоставляет её с реально установленной у вас версией.

🔴 Этот инструмент описывает расхождения между источниками данных, а не поведение какого-либо продукта. «Сообщит ли ваш сканер об этих 10 записях» зависит от того, какую базу он читает и как объединяет данные — это не проверялось, поэтому здесь об этом не написано.

Вторая половина не менее важна: только 2 из 14 записей срабатывают на конфигурации по умолчанию

Если сообщать только по номеру версии, то 12 записей, требующих особой конфигурации, тоже будут помечены как «вы затронуты» — это заставит вас делать то, что не нужно.

Поэтому при указании каталога установки инструмент читает все XML из conf/ (включая conf/Catalina/<host>/), удаляет блоки комментариев и затем ищет маркеры условий срабатывания. Удаление комментариев — не опция: в официальном server.xml текстовый поиск UpgradeProtocol даёт 1 совпадение, а после удаления комментариев — 0, потому что весь фрагмент закомментирован.

Для официальной чистой установки 8.5.100 результат выглядит так:

Если в той же конфигурации включить HTTP/2, RewriteValve и CGIServlet, «конфигурация подтверждена» становится 5.

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

Как определяется версия в распакованной установке

В именах jar из lib/ нет ни одного номера версии (это catalina.jar, а не catalina-8.5.100.jar). Инструменты, определяющие версию только по имени файла, в таких установках не распознают ничего — а «ничего не найдено» выглядит точно так же, как «вы в безопасности».

Этот инструмент определяет версию в таком порядке:

1. server.number из catalina.jar!/org/apache/catalina/util/ServerInfo.properties — именно его выводит собственный version.sh от Tomcat
2. Implementation-Version из META-INF/MANIFEST.MF
3. Имя файла (только для таких форм, как встроенный Tomcat в Spring Boot)

Если два источника не совпадают (ServerInfo.properties можно переопределить, это часто используют для скрытия версии), выводятся оба значения, выбор за вами.

Три черты, которые инструмент не переступает

Первое: подтвердить включение можно, подтвердить отсутствие — нельзя. «Не найдено» в отчёте означает «не найдено в просмотренных мной файлах», а не «у вас не включено». Конфигурация может находиться там, куда инструмент не смотрит: WEB-INF/web.xml внутри war, внешний CATALINA_BASE, параметры запуска. Поэтому категории «не затронут» не существует — всё, что не найдено, попадает в требует ручной проверки.

Второе: даже если найдено, это не всегда означает именно то. Например, в официальном server.xml по умолчанию AprLifecycleListener уже включён, но он лишь пытается загрузить нативную библиотеку — если библиотеки нет, APR-коннектор не активируется. Поэтому это «слабый маркер»: при совпадении сообщается только «возможно», а не «подтверждено».

Третье: версии 8.5, на которую можно обновиться, не существует. first_patched_version для всех 14 записей со стороны 8.5 — null. Это не «ещё не исправили», а «для 8.5 исправлять не будут». Единственный выход — перейти на другую ветку (9.0 / 10.1 / 11.0). Этот инструмент отвечает на вопрос «чем вы затронуты» и не делает вид, что может ответить «до какой версии 8.5 обновляться».

Ещё одна вещь, из-за которой вам может показаться, что «инструмент ошибается»: у одного CVE несколько оценок

Возьмём CVE-2025-55754 — все четыре числа настоящие:

Если смотреть только на NVD, можно решить, что это самая серьёзная запись; только на Apache — что можно игнорировать. Оба не ошибаются — Apache оценивает реальную эксплуатируемость при конфигурации по умолчанию, а CVSS считается механически по вектору, не учитывая, включена ли у вас эта функция.

Поэтому инструмент печатает все четыре числа и явно сообщает, когда две стороны расходятся в оценке.

Два набора терминов — не одно и то же; выравнивание делается только там, где это официально поддержано

Apache использует low / moderate / important / critical, GitHub — low / medium / high / critical. Основание для выравнивания —原文 с официальной security-impact.html от Tomcat:

Important / High — A vulnerability rated as Important (or High) impact is one which could result in the compromise of data or availability of the server.

→ Important и High — это два названия одного уровня, так написано самим проектом. 🔴 А вот официального заявления о соответствии moderate и medium нет, и инструмент сам их не приравнивает — Moderate от ASF описывает условия эксплуатируемости вроде «есть существенные смягчающие факторы / не влияет на типовую конфигурацию / требуется аутентификация», а medium от GitHub — это диапазон баллов CVSS; это разные вещи. В таком случае сообщается «официально эти два уровня не объявлены равными» и приводятся оба.

По такой методике из 14 записей 5 имеют существенно разные оценки (самый большой разрыв — CVE-2025-52520: Apache low / GitHub high), 2 не выравниваются, 7 совпадают.

Откуда данные и как их воспроизвести

Таблица判定 CveTable.java генерируется, ни одна строка не вписана вручную:

Перед публикацией/релизом дополнительно запускается проверка по независимой методике — она не читает указанный выше sources.json, а разбирает сгенерированный CveTable.java и затем ещё раз запрашивает NVD по cpe:

Этот шаг не для галочки: при первом же запуске он поймал настоящую ошибку. Генерирующий скрипт при определении «есть ли 8.5 в NVD» учитывал только случаи, где «нижняя граница диапазона начинается с 8.5», а в CVE-2025-24813 указано versionStartIncluding=None .. versionEndExcluding=9.0.99 — нижняя граница открыта, значит, 8.5 покрывается. Из-за этого разность посчитала на одну запись больше. Построчная проверка по cveId этого никогда бы не выявила; помогло только переключение на пользовательский подход «запросить 8.5.100 по cpe».

Сборка

Требуется JDK 17+. Во время выполнения ноль зависимостей, JUnit только для тестов.

License

MIT — см. LICENSE