shiro-check

Détecte les modules et versions d'Apache Shiro réellement installés, et détermine, un par un, lesquelles des 26 CVE officielles vous concernent vraiment.

Un seul jar sans dépendances, sans connexion réseau, sans lecture de votre pom — analyse directement les artefacts de build (jar / war / fat jar / répertoire).

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

---

Pourquoi il ne suffit pas de « jeter un œil au numéro de version »

Les CVE de Shiro ne sont pas rattachées à « Shiro » en général, mais à des modules précis. Un même identifiant correspond à des règles différentes selon le module :

CVE	Module affecté	Ceux qui n'utilisent que shiro-core
CVE-2020-17510	shiro-spring	Non concernés
CVE-2020-17523	shiro-web / shiro-spring / shiro-spring-boot-starter	Non concernés
CVE-2023-34478	shiro-web	Non concernés
CVE-2026-56091	shiro-guice	Non concernés

Sur les 26 entrées officielles, 13 ne touchent pas du tout shiro-core. Les réduire à une phrase du type « Shiro < 1.7.1 a des failles », c'est prendre à la place de l'utilisateur la décision qu'il devrait prendre lui-même — et la prendre à tort.

La granularité de décision de cet outil est CVE × module : les 26 CVE sont déployées en 37 règles, couvrant 7 modules.

Trois choses invisibles à une correspondance par coordonnées

1. 5 entrées n'apparaissent pas dans les alertes Dependabot

Dependabot fait correspondre les avis GitHub par coordonnées de dépendance. Sur les 26 entrées, 5 ne correspondent pas :

Entrée	Pourquoi elle ne correspond pas
CVE-2026-56091 (contournement d'authentification shiro-guice, high)	l'avis est toujours unreviewed, le paquet affecté est vide
CVE-2026-56130 (cookie RememberMe qui n'expire jamais)	idem
CVE-2014-0074 (contournement par mot de passe LDAP vide)	idem
CVE-2023-22602 (contournement d'authentification Spring Boot 2.6+, high)	l'avis est rattaché uniquement à org.apache.shiro:shiro-root
CVE-2010-3863	idem

Or shiro-root est le POM parent avec packaging=pom — sur Maven Central, il n'existe pas de jar correspondant (HTTP 404), aucun projet ne peut en dépendre, donc une correspondance par coordonnées ne pourra jamais le retrouver.

ℹ️ unreviewed est un état normal du processus GitHub (import automatique depuis la NVD, packages affectés pas encore annotés manuellement), et la correspondance par coordonnées est aussi une conception raisonnable. On se contente ici d'énoncer le fait « n'apparaît pas dans les alertes », sans dire que quelqu'un a fait une erreur.

2. L'uber jar contient d'autres modules

shiro-all est un uber jar qui empaquette plusieurs modules. Test effectué : shiro-all-1.3.2.jar contient en interne 6 META-INF/maven/org.apache.shiro/<module>/pom.properties :

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

Autrement dit, un projet dont le pom ne déclare que shiro-all ne possède qu'un seul nom au niveau des coordonnées (sur les 26 entrées, seule CVE-2016-6802 est rattachée à cette coordonnée), alors que le jar contient en réalité le code de trois modules : core / web / spring.

L'analyse des artefacts permet de percer cette couche. Testé sur un shiro-all-1.3.2.jar, cet outil signale 20 entrées réparties sur 3 modules.

3. Pour 3 entrées, la version officielle corrigée est introuvable sur Maven Central

Pour 3 avis, le first_patched_version est 3.0.0-alpha-2, or cette version n'a jamais été publiée sur Maven Central (l'éditeur a directement publié la version finale 3.0.0). Suivre cette indication pour mettre à jour ne mène à rien — l'outil le signale et remplace la recommandation de mise à jour par la version réellement disponible.

Un signalement ne signifie pas « vous êtes compromis »

« Correspondance » = ce module est présent et sa version tombe dans la plage officielle affectée. Cela ne signifie pas « déjà exploité » ni « nécessairement exploitable ».

La grande majorité des 26 entrées ne se vérifient qu'avec une configuration spécifique ; l'outil les liste donc séparément :

• 🔴 Affecté en configuration par défaut — à traiter en priorité (par ex. CVE-2026-43827, fixation de session)
• ⚠️ Nécessite des conditions spécifiques — les conditions sont données une par une ; si elles ne sont pas remplies, il n'y a pas de correspondance

Exemples de conditions (reprise littérale des descriptions officielles, sans extrapolation) :

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 路径;只影响静态文件

🔴 L'outil n'analyse pas votre configuration. Shiro peut être configuré dans shiro.ini / application.yml / le code Java, une conclusion issue d'une analyse serait plus dangereuse que l'absence d'analyse. Les conditions sont énumérées explicitement, à vous de juger — c'est un choix de conception délibéré, pas de la paresse.

Utilisation

# 扫一个 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

Capacité d'identification : jar ordinaire · Spring Boot fat jar (BOOT-INF/lib/) · WAR traditionnel (WEB-INF/lib/) · uber jar (shiro-all, avec les modules internes déployés) · jar renommé (déterminé par pom.properties) · archives malformées avec des chemins écrits en barres obliques inverses.

Nécessite JDK 17+. Zéro dépendance à l'exécution.

D'où vient la table de décision

Pas une seule ligne recopiée à la main. tools/gen_rules.py est généré à partir de deux sources primaires :

Source	Ce qu'elle fournit
shiro.apache.org/security-reports.html	Ensemble complet des entrées, texte original des descriptions, texte original des conditions de déclenchement
GitHub Advisory API	Coordonnées des modules affectés, plages de versions structurées, notation

Le processus de génération comporte 12 assertions ; si l'une d'elles n'est pas satisfaite, le processus s'arrête et n'écrit pas le fichier (pour éviter que « l'échec d'analyse génère une table vide alors que les tests restent tous verts ») :

• Intégrité : le décompte des CVE selon le critère des h3 du corps du texte et selon le critère des ancres du sommaire doit donner le même ensemble
• Traçabilité : pour les plages de versions renseignées manuellement, la chaîne de version doit apparaître mot pour mot dans le texte officiel d'origine
• Vérification empirique : l'appartenance à un module doit être confirmée par l'emplacement des classes dans le vrai jar (on n'accepte pas « je me souviens que celle-ci est dans le web »)
• Exécutabilité : chaque version corrective est vérifiée une fois sur Maven Central ; celles qui sont introuvables sont signalées
• Affirmations : le nombre d'angles morts de Dependabot, les différences entre modules, les modules contenus dans l'uber jar — tout cela doit toujours être valide

Avant publication, tools/recheck_before_publish.py revérifie les arguments porteurs avec un second ensemble de critères indépendant (sans importer le script de génération, ni lire sa sortie — réutiliser la même logique d'analyse reproduirait les bugs avec).

Limites