shiro-check

Individua i moduli e le versioni di Apache Shiro effettivamente installati, stabilendo caso per caso quali delle 26 CVE ufficiali ti riguardano davvero.

Singolo jar senza dipendenze, nessuna connessione di rete, non legge il tuo pom — scansiona direttamente gli artefatti di build (jar / war / fat jar / directory).

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

---

Perché non basta «dare un'occhiata al numero di versione e via»

Le CVE di Shiro non sono associate a «Shiro» nel suo complesso, ma a moduli specifici. Lo stesso identificativo segue regole diverse a seconda del modulo:

CVE	Moduli interessati	Chi usa solo shiro-core
CVE-2020-17510	shiro-spring	non interessato
CVE-2020-17523	shiro-web / shiro-spring / shiro-spring-boot-starter	non interessato
CVE-2023-34478	shiro-web	non interessato
CVE-2026-56091	shiro-guice	non interessato

Delle 26 voci ufficiali, 13 non toccano affatto shiro-core. Ridurle tutte a una frase come «Shiro < 1.7.1 ha delle falle» significa prendere al posto dell'utente una decisione che spetterebbe a lui — e prenderla in modo sbagliato.

La granularità di giudizio di questo strumento è CVE × modulo: le 26 CVE si espandono in 37 regole, che coprono 7 moduli.

Tre cose che la corrispondenza per coordinate non riesce a vedere

1. 5 voci non arrivano negli avvisi di Dependabot

Dependabot abbina gli advisory di GitHub in base alle coordinate delle dipendenze. Su 26 voci, 5 non corrispondono:

Voce	Perché non corrisponde
CVE-2026-56091 (bypass dell'autenticazione di shiro-guice, high)	l'advisory è ancora unreviewed, il pacchetto interessato è vuoto
CVE-2026-56130 (cookie RememberMe che non scade mai)	come sopra
CVE-2014-0074 (bypass tramite password LDAP vuota)	come sopra
CVE-2023-22602 (bypass dell'autenticazione di Spring Boot 2.6+, high)	l'advisory è associato solo a org.apache.shiro:shiro-root
CVE-2010-3863	come sopra

E shiro-root è il POM padre con packaging=pom — su Maven Central non esiste il jar corrispondente (HTTP 404), nessun progetto lo dichiara come dipendenza, quindi la corrispondenza per coordinate non lo intercetta mai.

ℹ️ unreviewed è uno stato normale del flusso di GitHub (importazione automatica da NVD, pacchetti interessati non ancora annotati manualmente), e anche la corrispondenza per coordinate è una scelta di progettazione ragionevole. Qui si afferma solo il fatto «non arrivano negli avvisi», non si sta dicendo che qualcuno abbia sbagliato.

2. Dentro l'uber jar si nascondono altri moduli

shiro-all è un uber jar che ingloba più moduli. In pratica, dentro shiro-all-1.3.2.jar ci sono 6 file META-INF/maven/org.apache.shiro/<modulo>/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,本工具报出 跨 3 个模块 20 条。

3. 有 3 条的官方修复版本在 Maven Central 上拿不到

3 条 advisory 的 first_patched_version 是 3.0.0-alpha-2,而这个版本从未发布到 Maven Central (官方直接发了 3.0.0 正式版)。照着它去升是升不动的 —— 本工具会标注出来,并把升级建议 换成实际拿得到的版本。

判定不等于「你中招了」

「命中」= 这个模块在场 且 版本落在官方受影响区间内。不等于「已被利用」或「必然可利用」。

26 条里绝大多数需要特定配置才成立,所以工具把它们分开列:

• 🔴 默认配置即受影响 —— 优先处理(如 CVE-2026-43827 session fixation)
• ⚠️ 需满足特定条件 —— 逐条给出条件,不满足就不中

条件示例(逐字对照官方描述原文,未作外推):

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

🔴 Lo strumento non analizza la tua configurazione. Shiro può essere configurato in shiro.ini / application.yml / codice Java, le conclusioni derivate dall'analisi sono più pericolose di nessuna analisi. Le condizioni sono elencate esplicitamente, spetta a te giudicare —— questa è una scelta di progettazione intenzionale, non pigrizia.

Utilizzo

# 扫一个 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à di identificazione: jar normali · Spring Boot fat jar (BOOT-INF/lib/) · WAR tradizionali (WEB-INF/lib/) · uber jar (shiro-all, con espansione dei moduli contenuti) · jar rinominati (fa fede pom.properties) · archivi malformati con percorsi scritti usando la barra rovesciata.

Richiede JDK 17+. Zero dipendenze a runtime.

Come è nata la tabella di valutazione

Nessuna riga è copiata a mano. tools/gen_rules.py la genera da due fonti primarie:

Fonte	Cosa fornisce
shiro.apache.org/security-reports.html	L'insieme completo delle voci, il testo originale delle descrizioni, il testo originale delle condizioni di attivazione
GitHub Advisory API	Le coordinate del modulo interessato, gli intervalli di versioni strutturati, la valutazione

Il processo di generazione include 12 asserzioni; se una qualsiasi non è soddisfatta, si interrompe e non scrive il file (per evitare che «il parsing fallisca, venga generata una tabella vuota e i test restino comunque tutti verdi»):

• Completezza: il criterio degli h3 nel corpo e quello degli anchor dell'indice devono contare lo stesso insieme di CVE
• Tracciabilità: per gli intervalli di versione inseriti manualmente, la stringa di versione deve comparire letteralmente nel testo ufficiale originale
• Verifica empirica: l'appartenenza ai moduli deve essere confermata dalla posizione delle classi nei jar reali (non si accetta «ricordo che questa è del web»)
• Eseguibilità: per ogni versione di correzione si effettua una ricerca su Maven Central; quelle non reperibili vengono segnalate
• Affermazioni: il numero di punti ciechi di Dependabot, le differenze tra moduli, i moduli contenuti negli uber jar — devono continuare a valere

Prima della pubblicazione c'è inoltre tools/recheck_before_publish.py, che ricontrolla gli argomenti portanti con un secondo criterio indipendente (non importa lo script di generazione né legge il suo output — riutilizzare la stessa logica di parsing riprodurrebbe anche i bug).

Limiti

• Copre solo le 26 voci presenti nella pagina ufficiale security-reports, esclusi problemi non divulgati o di integrazioni di terze parti
• Gli intervalli di versione provengono dalla documentazione ufficiale e da GitHub; quando i due criteri occasionalmente differiscono, fa fede l'intervallo strutturato sulle coordinate del modulo
• Non analizza la configurazione, quindi per le voci condizionali devi valutare tu se le condizioni sono soddisfatte
• La tabella di valutazione è uno snapshot al momento della generazione; GitHub può convertire unreviewed in reviewed in qualsiasi momento

---

English

shiro-check analizza gli artefatti della tua build (jar / war / fat jar / directory) per individuare quali moduli Apache Shiro distribuisci effettivamente, quindi valuta tutte le 26 CVE ufficiali rispetto alla tua esatta combinazione di modulo + versione.

Perché esiste: le CVE di Shiro sono associate ai moduli, non a "Shiro". 13 delle 26 non toccano mai shiro-core. Lo strumento opera a granularità CVE × modulo (37 regole, 7 moduli).

Tre cose che la corrispondenza basata sulle coordinate non può vedere: