shiro-check

Detecta los módulos y versiones de Apache Shiro que realmente tienes instalados y determina, una por una, cuáles de las 26 CVE oficiales te afectan realmente.

Un único jar sin dependencias, sin conexión a red, sin leer tu pom: escanea directamente los artefactos de compilación (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 y listo»

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

CVE	Módulos afectados	Quienes solo usan shiro-core
CVE-2020-17510	shiro-spring	No afectados
CVE-2020-17523	shiro-web / shiro-spring / shiro-spring-boot-starter	No afectados
CVE-2023-34478	shiro-web	No afectados
CVE-2026-56091	shiro-guice	No afectados

De las 26 oficiales, 13 no tocan en absoluto shiro-core. Reducirlas a una sola frase «Shiro < 1.7.1 tiene vulnerabilidades» es tomar por el usuario la decisión que él mismo debería tomar — y además tomarla mal.

La granularidad de detección 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. Cinco no llegan a las alertas de Dependabot

Dependabot hace coincidir las alertas de GitHub advisory por coordenadas de dependencia. De las 26, 5 no coinciden:

Entrada	Por qué no coincide
CVE-2026-56091 (omisión de autenticación en shiro-guice, high)	el advisory sigue como unreviewed, el paquete afectado está vacío
CVE-2026-56130 (la cookie RememberMe nunca caduca)	igual que arriba
CVE-2014-0074 (omisión de autenticación con contraseña LDAP vacía)	igual que arriba
CVE-2023-22602 (omisión de autenticación en Spring Boot 2.6+, high)	el advisory solo está asociado a org.apache.shiro:shiro-root
CVE-2010-3863	igual que arriba

Y shiro-root es el POM padre con packaging=pom — en Maven Central no existe el jar correspondiente (HTTP 404), ningún proyecto dependerá de él, así que la coincidencia por coordenadas nunca lo detectará.

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

2. Dentro del uber jar se esconden otros módulos

shiro-all es un uber jar que empaqueta varios módulos. En la práctica, shiro-all-1.3.2.jar contiene internamente 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 entradas, solo CVE-2016-6802 se asocia a esa coordenada), mientras que en el jar en realidad residen los códigos de tres módulos: core / web / spring.

Escanear el artefacto real permite ver a través de esta capa. En una prueba real con un shiro-all-1.3.2.jar, esta herramienta reporta 20 entradas distribuidas en 3 módulos.

3. Hay 3 entradas 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 (el proyecto oficial publicó directamente la versión estable 3.0.0). Actualizar siguiendo esa indicación no es posible: esta herramienta lo señala y sustituye la recomendación de actualización por la versión que realmente está disponible.

La detección no equivale a «fuiste comprometido»

«Coincidencia» = este módulo está presente y la versión cae dentro del rango oficialmente afectado. No equivale a «ya explotado» ni a «necesariamente explotable».

La gran mayoría de las 26 entradas solo se cumplen con configuraciones específicas, por lo que la herramienta las enumera por separado:

• 🔴 Afectado con la configuración predeterminada — prioridad de tratamiento (p. ej., CVE-2026-43827 session fixation)
• ⚠️ Requiere cumplir condiciones específicas — se indica la condición para cada entrada; si no se cumple, no hay afectación

Ejemplos de condiciones (contrastados literalmente con el texto original de la descripción oficial, sin extrapolación):

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 en shiro.ini / application.yml / código Java, y la conclusión obtenida del análisis es más peligrosa que no analizarla. Las condiciones se enumeran explícitamente para que tú mismo las evalúes — esto es un diseño intencional, 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 identificación: jar normal · Spring Boot fat jar (BOOT-INF/lib/) · WAR tradicional (WEB-INF/lib/) · uber jar (shiro-all, expandiendo los módulos contenidos) · jar renombrado (según pom.properties) · archivos malformados con rutas escritas usando barras invertidas.

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

Cómo se genera la tabla de determinación

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

Fuente	Qué proporciona
shiro.apache.org/security-reports.html	Conjunto completo de entradas, texto original de las descripciones, texto original de las condiciones de activación
GitHub Advisory API	Coordenadas de módulo afectadas, rangos de versiones estructurados, calificación

El proceso de generación incluye 12 aserciones; si alguna no se cumple, se aborta y no se escribe el archivo (para evitar que «una falla de análisis genere una tabla vacía y las pruebas sigan pasando en verde»):

• Integridad: el criterio de los h3 del cuerpo y el criterio de los anclajes del índice deben contabilizar el mismo conjunto de CVE
• Trazabilidad: para los rangos de versiones introducidos manualmente, la cadena de versión debe aparecer literalmente en el texto oficial original
• Verificación empírica: la pertenencia al módulo debe confirmarse mediante la ubicación de la clase en el jar real (no se acepta «recuerdo que esta era de web»)
• Ejecutabilidad: cada versión de corrección se consulta una vez en Maven Central; las que no estén disponibles 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 — todos deben seguir siendo válidos

Antes de publicar existe además tools/recheck_before_publish.py, que vuelve a verificar los argumentos fundamentales 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