shiro-check

Descubre qué módulos y versiones de Apache Shiro tienes realmente instalados y determina, una por una, cuáles de las 26 CVE oficiales te afectan de verdad.

Un único jar sin dependencias, sin conexión de red, sin leer tu pom: escanea directamente los artefactos compilados (jar / war / fat jar / directorio).

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

Por qué no basta con «mirar el número de versión»

Las CVE de Shiro no están asociadas a «Shiro» en general, sino a módulos concretos. El mismo identificador tiene reglas distintas según el módulo:

De las 26 oficiales, 13 no tocan shiro-core en absoluto. Reducirlas a una frase tipo «Shiro < 1.7.1 tiene agujeros» es hacer por el usuario el juicio que debería hacer él mismo — y hacerlo mal.

La granularidad de esta herramienta es CVE × módulo: las 26 CVE se despliegan en 37 reglas que cubren 7 módulos.

Tres cosas que la coincidencia por coordenadas no puede ver

1. 5 entradas que no llegan a las alertas de Dependabot

Dependabot empareja los avisos de GitHub por coordenadas de dependencia. De las 26, hay 5 que no coinciden:

Y shiro-root es el POM padre con packaging=pom: en Maven Central no hay ningún jar correspondiente (HTTP 404), ningún proyecto depende de él, por lo que la coincidencia por coordenadas nunca puede acertar.

ℹ️ unreviewed es un estado normal del flujo de GitHub (importación automática desde NVD, sin etiquetado manual de paquetes afectados todavía), y la coincidencia por coordenadas es un diseño razonable. Aquí solo se constata el hecho de que «no llegan a las alertas», no que alguien lo haya informado mal.

2. El uber jar esconde otros módulos dentro

shiro-all es un uber jar que empaqueta varios módulos. En la práctica, shiro-all-1.3.2.jar contiene 6 META-INF/maven/org.apache.shiro/<módulo>/pom.properties:

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

Es decir, un proyecto cuyo pom solo declara shiro-all tiene un único nombre a nivel de coordenadas (de las 26 CVE, solo CVE-2016-6802 está asociada a esta coordenada), pero dentro del jar hay realmente código de los módulos core / web / spring.

Escaneando el artefacto real se ve a través de esa capa. En la práctica, con un shiro-all-1.3.2.jar, la herramienta reporta 20 reglas repartidas en 3 módulos.

3. Hay 3 cuya versión oficial de corrección no está disponible en Maven Central

El first_patched_version de 3 advisories es 3.0.0-alpha-2, y esa versión nunca se publicó en Maven Central (la versión estable 3.0.0 se publicó directamente). Actualizar siguiendo esa indicación es imposible: la herramienta lo marca y sustituye la recomendación de actualización por una versión que sí se puede obtener.

Una coincidencia no significa «estás comprometido»

«Coincidencia» = el módulo está presente Y la versión está dentro del rango afectado oficial. No equivale a «explotado» ni a «explotable con seguridad».

De las 26, la gran mayoría solo se materializa con una configuración específica, por lo que la herramienta las presenta por separado:

• 🔴 Afectado con la configuración por defecto — tratar con prioridad (p. ej., CVE-2026-43827 session fixation)
• ⚠️ Requiere condiciones específicas — las condiciones se dan una a una; si no se cumplen, no aplica

Ejemplos de condiciones (transcritas literalmente del texto oficial, sin extrapolar):

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

🔴 La herramienta no analiza tu configuración. Shiro se puede configurar tanto en shiro.ini / application.yml / código Java; una conclusión obtenida analizándola sería más peligrosa que no analizarla. Las condiciones se listan explícitamente y eres tú quien decide — es una decisión deliberada, no pereza.

Uso

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

Capacidad de reconocimiento: jar normal · Spring Boot fat jar (BOOT-INF/lib/) · WAR tradicional (WEB-INF/lib/) · uber jar (shiro-all, expandiendo los módulos internos) · jars renombrados (según pom.properties) · archivos comprimidos malformados con rutas en barra invertida.

Requiere JDK 17+. Sin dependencias en tiempo de ejecución.

De dónde sale la tabla de reglas

Ni una línea copiada a mano. tools/gen_rules.py la genera a partir de dos fuentes primarias:

El proceso de generación incorpora 12 aserciones; si alguna no se cumple, aborta sin escribir el archivo (para evitar que un fallo de análisis genere una tabla vacía y que los tests sigan en verde):

• Integridad: el criterio de los h3 del cuerpo y el de las anclas del índice deben contar exactamente el mismo conjunto de CVE.
• Trazabilidad: las cadenas de versión de los rangos rellenados manualmente deben aparecer literalmente en el texto oficial.
• Verificación empírica: la asignación de módulos debe estar confirmada por la ubicación de las clases en un jar real (no se acepta «recuerdo que esta es de web»).
• Ejecutable: cada versión de corrección se comprueba contra Maven Central; las que no se pueden obtener se marcan.
• Afirmaciones: el número de puntos ciegos de Dependabot, las diferencias entre módulos y los módulos contenidos en el uber jar — todo debe seguir siendo cierto.

Antes de publicar, además, tools/recheck_before_publish.py vuelve a verificar los argumentos de peso con un segundo criterio independiente (no importa el script de generación ni lee su salida — reutilizar la misma lógica de análisis reproduciría también los bugs).

Limitaciones

• Solo cubre las 26 entradas de la página oficial de security-reports; no incluye problemas no divulgados ni de integraciones de terceros.
• Los rangos de versiones provienen de las fuentes oficiales y de GitHub; cuando ambos criterios difieren ocasionalmente, prevalece el rango estructurado asociado a la coordenada del módulo.
• No analiza la configuración, por lo que las entradas condicionales requieren que tú mismo juzgues si se cumplen.
• La tabla de reglas es una instantánea del momento de generación; GitHub puede pasar unreviewed a reviewed en cualquier momento.

Inglés

shiro-check escanea tus artefactos de compilación (jar / war / fat jar / directorio) para detectar qué módulos de Apache Shiro incluyes realmente y, después, evalúa las 26 CVE oficiales sobre tu combinación exacta de módulo + versión.

Por qué existe: las CVE de Shiro se asignan a módulos, no a «Shiro». 13 de las 26 no tocan shiro-core en absoluto. La herramienta trabaja con una granularidad de CVE × módulo (37 reglas, 7 módulos).

Tres cosas que la coincidencia por coordenadas no puede ver:

1. 5 entradas nunca llegan a las alertas de Dependabot: 3 advisories siguen unreviewed con la lista de paquetes afectados vacía; 2 están asociados únicamente a org.apache.shiro:shiro-root, que es un POM padre con packaging=pom y no tiene jar en Maven Central (HTTP 404), por lo que ningún proyecto depende de él.
2. shiro-all es un uber jar: shiro-all-1.3.2.jar contiene 6 entradas pom.properties (core, web, spring, ehcache, quartz y él mismo). Tu pom muestra una coordenada; el jar contiene código de tres módulos.
3. 3 advisories señalan 3.0.0-alpha-2 como corrección, una versión que nunca se publicó en Maven Central. La herramienta las marca y sugiere una versión a la que sí puedes actualizar.

Una «coincidencia» significa módulo presente Y versión dentro del rango afectado oficial. No significa explotable: la mayoría de las entradas requieren una configuración específica, que la herramienta lista literalmente del advisory oficial. Deliberadamente no analiza tu configuración.

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

Requiere JDK 17+. Sin dependencias en tiempo de ejecución. La tabla de reglas se genera a partir de dos fuentes primarias con 12 aserciones que abortan si fallan; ver tools/gen_rules.py.

Licencia

Apache License 2.0