shiro-check

Определяет, какие модули и версии Apache Shiro вы фактически поставляете, и по каждой из 26 официальных CVE показывает, какие из них действительно вас касаются.

Один jar без зависимостей, без сети, не читает ваш pom — сканирует непосредственно артефакты сборки (jar / war / fat jar / каталог).

java -jar shiro-check.jar --utf8 your-app.jar

Почему нельзя «просто посмотреть на номер версии»

CVE в Shiro привязаны не к «Shiro», а к конкретным модулям. Один и тот же номер в разных модулях — это разные правила:

Из официальных 26 записей 13 вообще не касаются shiro-core. Сжать их во фразу «Shiro < 1.7.1 уязвим» — значит принять за пользователя решение, которое он должен принимать сам. И это решение ошибочно.

Гранулярность определения этого инструмента — CVE × модуль: 26 CVE разворачиваются в 37 правил, покрывающих 7 модулей.

Три вещи, невидимые при сопоставлении по координатам

1. 5 записей не попадают в предупреждения Dependabot

Dependabot сопоставляет рекомендации GitHub по координатам зависимостей. Из 26 записей 5 не сходятся:

А shiro-root — это родительский POM с packaging=pom. На Maven Central нет соответствующего jar (HTTP 404), ни один проект от него не зависит, поэтому сопоставление по координатам никогда не сойдётся.

ℹ️ unreviewed — это нормальное состояние процесса в GitHub (автоматический импорт из NVD, затронутые пакеты ещё не размечены вручную); сопоставление по координатам — тоже разумное проектное решение. Здесь лишь констатируется факт «не попадает в предупреждения», а не чья-то ошибка.

2. В uber jar спрятаны другие модули

shiro-all — это uber jar, упаковывающий в себя несколько модулей. Проверено на практике: внутри shiro-all-1.3.2.jar находятся 6 файлов META-INF/maven/org.apache.shiro/<模块>/pom.properties:

shiro-all  shiro-core  shiro-web  shiro-spring  shiro-ehcache  shiro-quartz

То есть у проекта, в pom которого указан только shiro-all, на уровне координат есть лишь одно имя (из 26 записей только CVE-2016-6802 висит на этой координате), а внутри jar в действительности лежит код трёх модулей — core / web / spring.

Сканирование реального артефакта позволяет увидеть этот слой. Проверено на shiro-all-1.3.2.jar: инструмент выдаёт 20 записей в 3 модулях.

3. Для 3 записей официальная версия исправления недоступна на Maven Central

У 3 рекомендаций first_patched_version — это 3.0.0-alpha-2, и эта версия никогда не публиковалась на Maven Central (официально сразу вышел финальный 3.0.0). Обновиться до неё невозможно — инструмент помечает такие случаи и заменяет рекомендацию по обновлению на версию, которую реально можно получить.

Вердикт не означает «вы затронуты»

«Попадание» = этот модуль присутствует И версия попадает в официальный диапазон затронутых версий. Это не равно «уже эксплуатируется» или «обязательно эксплуатируемо».

Подавляющее большинство из 26 записей срабатывает только при определённой конфигурации, поэтому инструмент перечисляет их раздельно:

• 🔴 Уязвим при конфигурации по умолчанию — обрабатывать в первую очередь (например, CVE-2026-43827, фиксация сессии)
• ⚠️ Требуются определённые условия — для каждой записи приводится условие; не выполнено — не затронут

Примеры условий (дословно по оригинальному тексту официальных описаний, без экстраполяций):

CVE-2026-49268  仅当使用 DefaultLdapRealm(用户名未转义即拼进 LDAP DN)
CVE-2023-22602  仅当与 Spring Boot 2.6+ 一起使用,且未把
                spring.mvc.pathmatch.matching-strategy 设回 ant_path_matcher
CVE-2026-23903  仅当静态文件放在大小写不敏感的文件系统上(如 macOS 默认设置),
                且 Shiro 里只配了小写的 filter 路径;只影响静态文件

🔴 Инструмент не разбирает вашу конфигурацию. Shiro можно настроить в shiro.ini / application.yml / Java-коде; вывод, полученный парсингом, опаснее, чем его отсутствие. Условия перечислены открытым текстом, и решение принимаете вы — это осознанное проектное решение, а не лень.

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

# 扫一个 jar / war
java -jar shiro-check.jar your-app.jar

# 扫整个目录(递归)
java -jar shiro-check.jar /path/to/libs

# 连「不适用」的条目也列出来
java -jar shiro-check.jar --all your-app.jar

# Windows 控制台中文乱码时
java -jar shiro-check.jar --utf8 your-app.jar

Что распознаёт: обычные jar · Spring Boot fat jar (BOOT-INF/lib/) · классические WAR (WEB-INF/lib/) · uber jar (shiro-all, с разворачиванием вложенных модулей) · переименованные jar (ориентир — pom.properties) · некорректные архивы, в которых пути записаны через обратную косую черту.

Требуется JDK 17+. В рантайме ноль зависимостей.

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

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

Процесс генерации сопровождается 12 проверками-утверждениями; если хоть одна не выполнена, генерация останавливается и файл не записывается (защита от ситуации «парсер сломался, таблица вышла пустой, а тесты по-прежнему зелёные»):

• Полнота: по заголовкам h3 в тексте и по якорям в оглавлении должно насчитываться одно и то же множество CVE
• Прослеживаемость: для вручную заполненных диапазонов версий строки версий должны дословно встречаться в официальном тексте
• Проверка на практике: принадлежность модуля должна подтверждаться расположением классов в реальном jar (не принимается «я помню, что эта запись про web»)
• Исполняемость: каждая версия исправления проверяется на Maven Central; недоступные помечаются
• Утверждения: число записей в слепой зоне Dependabot, межмодульные различия, модули внутри uber jar — всё это должно по-прежнему выполняться

Перед публикацией дополнительно запускается tools/recheck_before_publish.py, который по второй, независимой методике заново проверяет несущие аргументы (не импортирует скрипт генерации и не читает его вывод — повторное использование той же логики разбора воспроизвело бы и баги вместе с ней).

Ограничения

• Покрываются только 26 записей с официальной страницы security-reports; непубличные проблемы и проблемы сторонних интеграций не включены
• Диапазоны версий взяты из официального источника и GitHub; при редких расхождениях между ними приоритет у структурированного диапазона по координате модуля
• Конфигурация не разбирается, поэтому для условных записей нужно самостоятельно оценить, выполнено ли условие
• Таблица вердиктов — снимок на момент генерации; GitHub в любой момент может перевести unreviewed в reviewed

Английский

shiro-check сканирует ваши артефакты сборки (jar / war / fat jar / каталог), чтобы определить, какие модули Apache Shiro вы фактически поставляете, а затем оценивает все 26 официальных CVE применительно к вашей точной комбинации модуль + версия.

Зачем это нужно: CVE в Shiro привязаны к модулям, а не к «Shiro». 13 из 26 вообще не касаются shiro-core. Инструмент работает на гранулярности CVE × модуль (37 правил, 7 модулей).

Три вещи, которые не видит сопоставление по координатам:

1. 5 записей никогда не попадают в предупреждения Dependabot — 3 рекомендации всё ещё в статусе unreviewed с пустым списком затронутых пакетов; ещё 2 прикреплены только к org.apache.shiro:shiro-root, а это родительский POM с packaging=pom, у которого нет jar на Maven Central (HTTP 404), поэтому ни один проект никогда от него не зависит.
2. shiro-all — это uber jar — внутри shiro-all-1.3.2.jar содержатся 6 записей pom.properties (core, web, spring, ehcache, quartz + он сам). В вашем pom видна одна координата; внутри jar лежит код трёх модулей.
3. В 3 рекомендациях версией исправления указана 3.0.0-alpha-2 — версия, которая никогда не публиковалась на Maven Central. Инструмент помечает такие случаи и предлагает версию, до которой реально можно обновиться.

«Попадание» означает модуль присутствует И версия находится в официальном затронутом диапазоне. Это не означает эксплуатируемость — большинство записей требует определённой конфигурации, которую инструмент приводит дословно из официальной рекомендации. Он осознанно не разбирает вашу конфигурацию.

java -jar shiro-check.jar [--all] [--utf8] <jar | war | directory> ...

Требуется JDK 17+. Без зависимостей в рантайме. Таблица правил генерируется из двух первоисточников с 12 проверками-утверждениями, которые останавливают генерацию при сбое; см. tools/gen_rules.py.

Лицензия

Apache License 2.0