shiro-check

Ermittelt die tatsächlich installierten Apache-Shiro-Module und -Versionen und prüft Eintrag für Eintrag, welche der offiziellen 26 CVEs wirklich auf dich zutreffen.

Ein einziges Jar ohne Abhängigkeiten, keine Netzwerkverbindung, liest deine pom nicht – scannt direkt die Build-Artefakte (jar / war / fat jar / Verzeichnis).

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

---

Warum es nicht reicht, „nur kurz auf die Versionsnummer zu schauen“

Shiros CVEs hängen nicht an „Shiro“, sondern an konkreten Modulen. Dieselbe Nummer hat in verschiedenen Modulen unterschiedliche Regeln:

CVE	Betroffenes Modul	Wer nur shiro-core verwendet
CVE-2020-17510	shiro-spring	nicht betroffen
CVE-2020-17523	shiro-web / shiro-spring / shiro-spring-boot-starter	nicht betroffen
CVE-2023-34478	shiro-web	nicht betroffen
CVE-2026-56091	shiro-guice	nicht betroffen

Von den offiziellen 26 Einträgen betreffen 13 shiro-core überhaupt nicht. Sie zu einem Satz wie „Shiro < 1.7.1 hat Lücken“ zu verdichten, heiße, dem Nutzer die Entscheidung abzunehmen, die er selbst treffen sollte – und sie dabei falsch zu treffen.

Die Beurteilungsgranularität dieses Tools ist CVE × Modul: 26 CVEs werden zu 37 Regeln, die 7 Module abdecken, entfaltet.

Drei Dinge, die bei der Zuordnung nach Koordinaten unsichtbar bleiben

1. 5 Einträge gelangen nicht in Dependabot-Warnungen

Dependabot gleicht GitHub-Advisories anhand von Abhängigkeitskoordinaten ab. Von den 26 Einträgen stimmen 5 nicht überein:

Eintrag	Warum keine Übereinstimmung
CVE-2026-56091 (shiro-guice-Authentifizierungsumgehung, high)	Das Advisory ist weiterhin unreviewed, das betroffene Paket ist leer
CVE-2026-56130 (RememberMe-Cookie läuft nie ab)	Wie oben
CVE-2014-0074 (LDAP-Umgehung bei leerem Passwort)	Wie oben
CVE-2023-22602 (Spring Boot 2.6+ Authentifizierungsumgehung, high)	Das Advisory ist nur an org.apache.shiro:shiro-root gehängt
CVE-2010-3863	Wie oben

Und shiro-root ist ein Parent-POM mit packaging=pom – auf Maven Central gibt es kein entsprechendes jar (HTTP 404), kein Projekt hängt davon ab, daher lässt es sich über die Koordinaten-Zuordnung niemals treffen.

ℹ️ unreviewed ist ein normaler Prozesszustand von GitHub (NVD-Autoimport, betroffene Pakete noch nicht manuell gekennzeichnet), auch die Zuordnung nach Koordinaten ist ein sinnvolles Design. Hier wird nur die Tatsache „gelangt nicht in Warnungen“ festgestellt, nicht behauptet, jemand habe einen Fehler gemeldet.

2. Im Uber-Jar verbergen sich andere Module

shiro-all ist ein Uber-Jar, in das mehrere Module gepackt sind. Gemessen enthält shiro-all-1.3.2.jar intern 6 META-INF/maven/org.apache.shiro/<Modul>/pom.properties:

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

Das heißt, ein Projekt, das in der pom nur shiro-all deklariert, hat auf Koordinatenebene nur einen einzigen Namen (von den 26 Einträgen hängt nur CVE-2016-6802 an dieser Koordinate), während im jar tatsächlich der Code von drei Modulen liegt: core / web / spring.

Durch das Scannen der tatsächlichen Artefakte lässt sich diese Ebene durchschauen. In einem realen Test mit einer shiro-all-1.3.2.jar meldet dieses Tool 20 Einträge über 3 Module hinweg.

3. Bei 3 Einträgen ist die offizielle Fix-Version nicht über Maven Central erhältlich

Bei 3 Advisories ist first_patched_version gleich 3.0.0-alpha-2, und diese Version wurde nie auf Maven Central veröffentlicht (offiziell wurde direkt die finale Version 3.0.0 veröffentlicht). Ein Upgrade entsprechend dieser Angabe lässt sich nicht durchführen – dieses Tool kennzeichnet das und ersetzt die Upgrade-Empfehlung durch die tatsächlich erhältliche Version.

Eine Feststellung bedeutet nicht „Sie sind betroffen"

„Treffer" = dieses Modul ist vorhanden und die Version liegt im offiziell betroffenen Bereich. Das bedeutet nicht „bereits ausgenutzt" oder „zwangsläufig ausnutzbar".

Die überwiegende Mehrheit der 26 Einträge setzt eine bestimmte Konfiguration voraus, daher listet das Tool sie getrennt auf:

• 🔴 Bereits in der Standardkonfiguration betroffen – vorrangig behandeln (z. B. CVE-2026-43827 session fixation)
• ⚠️ Erfordert bestimmte Bedingungen – die Bedingungen werden jeweils einzeln angegeben; sind sie nicht erfüllt, besteht keine Betroffenheit

Beispiele für Bedingungen (wörtlich nach dem Original der offiziellen Beschreibung, ohne 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 路径;只影响静态文件

🔴 Das Tool parst deine Konfiguration nicht. Shiro kann in shiro.ini / application.yml / Java-Code konfiguriert werden, die daraus gezogenen Schlussfolgerungen sind gefährlicher als gar keine Analyse. Die Bedingungen werden im Klartext aufgelistet, die Beurteilung liegt bei dir — das ist bewusstes Design, keine Faulheit.

Verwendung

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

Erkennungsfähigkeit: normales jar · Spring Boot Fat jar (BOOT-INF/lib/) · traditionelles WAR (WEB-INF/lib/) · uber jar (shiro-all, mit expandierten enthaltenen Modulen) · umbenanntes jar (maßgeblich ist pom.properties) · fehlerhafte Archive mit Backslash-Pfaden.

Erfordert JDK 17+. Null Abhängigkeiten zur Laufzeit.

Woher die Entscheidungstabelle kommt

Keine einzige Zeile manuell abgeschrieben. tools/gen_rules.py generiert sie aus zwei Primärquellen:

Quelle	Was sie liefert
shiro.apache.org/security-reports.html	Vollständige Liste der Einträge, Originalbeschreibungen, Originalauslösebedingungen
GitHub Advisory API	Betroffene Modulkoordinaten, strukturierte Versionsbereiche, Einstufung

Der Generierungsprozess enthält 12 Assertions; wird eine davon nicht erfüllt, wird abgebrochen und keine Datei geschrieben (um zu verhindern, dass „bei fehlgeschlagenem Parsing eine leere Hülltabelle generiert wird und die Tests trotzdem alle grün sind“):

• Vollständigkeit: Die h3-Kriterien im Fließtext und die Kriterien der Verzeichnisanker müssen dieselbe Menge an CVEs ergeben
• Rückverfolgbarkeit: Bei manuell eingetragenen Versionsbereichen muss die Versionszeichenkette wörtlich im offiziellen Originaltext vorkommen
• Praktische Überprüfung: Die Modulzuordnung muss durch die Klassenposition im echten jar belegt sein (es wird nicht akzeptiert: „Ich erinnere mich, dass dieser Eintrag zum Web-Modul gehört“)
• Ausführbarkeit: Für jede Fix-Version wird Maven Central einmal abgefragt; nicht abrufbare werden gekennzeichnet
• Behauptungen: Die Anzahl der Dependabot-Blindstellen, modulübergreifende Unterschiede, in uber jar enthaltene Module – all dies muss weiterhin zutreffen

Vor der Veröffentlichung gibt es zusätzlich tools/recheck_before_publish.py, das mit einem zweiten, unabhängigen Kriteriensatz die tragenden Argumente erneut prüft (es importiert das Generierungsskript nicht und liest auch dessen Ausgabe nicht – bei Wiederverwendung derselben Parsing-Logik würden Bugs mit reproduziert).

Einschränkungen