xiaoqimikko/shiro-checkВыявляет фактически установленные у вас модули и версии Apache Shiro и по каждому пункту определяет, какие из 26 официальных CVE действительно вас затрагивают. Определение по принципу «CVE × модуль», без зависимостей, один jar. CVE-2026-49268
Определяет фактически установленные модули и версии Apache Shiro и по каждому пункту проверяет, какие из 26 официальных CVE действительно затрагивают вашу систему.
Единственный jar без зависимостей, без подключения к сети, не читает ваш pom — напрямую сканирует артефакты сборки (jar / war / fat jar / каталог).
java -jar shiro-check.jar --utf8 your-app.jar
CVE в Shiro привязаны не к «Shiro» в целом, а к конкретным модулям. Один и тот же номер в разных модулях означает разные правила:
| CVE | Затронутый модуль | Те, кто использует только shiro-core |
|---|---|---|
| CVE-2020-17510 | shiro-spring | Не затронуты |
| CVE-2020-17523 | shiro-web / shiro-spring / shiro-spring-boot-starter | Не затронуты |
| CVE-2023-34478 | shiro-web | Не затронуты |
| CVE-2026-56091 | shiro-guice | Не затронуты |
Из 26 официальных записей 13 вообще не касаются shiro-core. Свести их к одной фразе «в Shiro < 1.7.1 есть уязвимости» —
значит принять за пользователя решение, которое он должен принять сам, — и притом принять его неверно.
Гранулярность проверки в этом инструменте — CVE × модуль: 26 CVE развёрнуты в 37 правил, охватывающих 7 модулей.
Dependabot сопоставляет зависимости по координатам с GitHub advisory. Из 26 записей 5 не совпадают:
| Запись | Почему не совпадает |
|---|---|
| CVE-2026-56091 (обход аутентификации shiro-guice, high) | advisory всё ещё unreviewed, список затронутых пакетов пуст |
| CVE-2026-56130 (cookie RememberMe никогда не истекает) | то же самое |
| CVE-2014-0074 (обход при пустом пароле LDAP) | то же самое |
| CVE-2023-22602 (обход аутентификации Spring Boot 2.6+, high) | advisory привязан только к org.apache.shiro:shiro-root |
| CVE-2010-3863 | то же самое |
А shiro-root — это родительский POM с packaging=pom — на Maven Central
нет соответствующего jar (HTTP 404),
ни один проект от него не зависит, поэтому сопоставление по координатам никогда не сработает.
ℹ️
unreviewed— это нормальное состояние процесса на GitHub (автоматический импорт из NVD, затронутые пакеты ещё не размечены вручную), и сопоставление по координатам — тоже разумный подход. Здесь лишь констатируется факт «не попадает в оповещения», а не утверждается, что кто-то ошибся.
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 advisory значение first_patched_version равно 3.0.0-alpha-2, но эта версия никогда не публиковалась на Maven Central
(официально сразу выпущена финальная версия 3.0.0). Обновление до неё невозможно — данный инструмент это отмечает и заменяет рекомендацию по обновлению
на фактически доступную версию.
«Совпадение» = этот модуль присутствует и его версия попадает в официальный диапазон затронутых версий. Это не означает «уже эксплуатируется» или «обязательно эксплуатируемо».
Подавляющее большинство из 26 записей срабатывает только при определённой конфигурации, поэтому инструмент выводит их раздельно:
Примеры условий (дословно по оригинальному тексту официального описания, без экстраполяции):
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 генерирует её из двух первоисточников:
| Источник | Что предоставляет |
|---|---|
| shiro.apache.org/security-reports.html | Полный набор записей, оригинальные тексты описаний, оригинальные тексты условий срабатывания |
| GitHub Advisory API | Затронутые координаты модулей, структурированные диапазоны версий, рейтинг |
Процесс генерации содержит 12 утверждений; если хотя бы одно не выполняется, процесс прерывается и файл не записывается (защита от ситуации «разбор не удался, сгенерирована пустая таблица, а тесты всё равно зелёные»):
Перед публикацией дополнительно запускается tools/recheck_before_publish.py, который перепроверяет несущие аргументы по второму независимому набору правил
(он не импортирует скрипт генерации и не читает его вывод — повторное использование той же логики разбора привело бы к воспроизведению и ошибок вместе с ней).
unreviewed в reviewed