shiro-check

Detecte os módulos e versões do Apache Shiro que você realmente instalou e determine, item por item, quais das 26 CVEs oficiais realmente se aplicam ao seu caso.

Jar único sem dependências, sem conexão à internet, sem ler seu pom — escaneia diretamente os artefatos de build (jar / war / fat jar / diretório).

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

---

Por que não é só «olhar a versão e pronto»

As CVE do Shiro não estão associadas ao «Shiro», mas sim a módulos específicos. O mesmo número tem regras diferentes em módulos diferentes:

CVE	Módulos afetados	Quem usa apenas shiro-core
CVE-2020-17510	shiro-spring	Não afetado
CVE-2020-17523	shiro-web / shiro-spring / shiro-spring-boot-starter	Não afetado
CVE-2023-34478	shiro-web	Não afetado
CVE-2026-56091	shiro-guice	Não afetado

Das 26 oficiais, 13 não tocam em shiro-core de forma alguma. Reduzi-las a uma frase como «Shiro < 1.7.1 tem falhas» é tomar pelo usuário a decisão que ele mesmo deveria tomar — e tomá-la errado.

A granularidade de avaliação desta ferramenta é CVE × módulo: as 26 CVE se desdobram em 37 regras, cobrindo 7 módulos.

Três coisas que a correspondência por coordenadas não vê

1. 5 não entram nos alertas do Dependabot

O Dependabot corresponde os avisos do GitHub por coordenadas de dependência. Das 26 entradas, 5 não correspondem:

Entrada	Por que não corresponde
CVE-2026-56091 (bypass de autenticação do shiro-guice, high)	o aviso ainda está unreviewed, pacote afetado vazio
CVE-2026-56130 (cookie RememberMe nunca expira)	idem
CVE-2014-0074 (bypass de senha vazia no LDAP)	idem
CVE-2023-22602 (bypass de autenticação do Spring Boot 2.6+, high)	o aviso está vinculado apenas a org.apache.shiro:shiro-root
CVE-2010-3863	idem

E shiro-root é o POM pai com packaging=pom — no Maven Central não há jar correspondente (HTTP 404), nenhum projeto depende dele, então a correspondência por coordenadas nunca o encontra.

ℹ️ unreviewed é um estado normal do fluxo do GitHub (importação automática do NVD, pacotes afetados ainda não anotados manualmente), e a correspondência por coordenadas também é um design razoável. Aqui apenas se declara o fato de «não entrar nos alertas», não que alguém tenha reportado errado.

2. O uber jar contém outros módulos

shiro-all é um uber jar que empacota vários módulos. Testes mostram que shiro-all-1.3.2.jar contém internamente 6 META-INF/maven/org.apache.shiro/<módulo>/pom.properties:

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

Ou seja, um projeto que declara apenas shiro-all no pom tem, no nível de coordenadas, apenas um único nome (das 26 entradas, apenas a CVE-2016-6802 está associada a essa coordenada), enquanto o jar contém, na prática, o código de três módulos: core / web / spring.

A varredura do artefato real permite enxergar através dessa camada. Em um teste com um shiro-all-1.3.2.jar, esta ferramenta reportou 20 entradas distribuídas por 3 módulos.

3. Há 3 entradas cuja versão oficial de correção não está disponível no Maven Central

O first_patched_version de 3 advisories é 3.0.0-alpha-2, e essa versão nunca foi publicada no Maven Central (a versão oficial lançada foi diretamente a 3.0.0 final). Seguir essa indicação para atualizar não funciona — esta ferramenta sinaliza isso e substitui a recomendação de atualização pela versão efetivamente disponível.

A detecção não equivale a «você foi comprometido»

«Acerto» = este módulo está presente e a versão está dentro do intervalo oficialmente afetado. Não equivale a «já explorado» nem a «inevitavelmente explorável».

A grande maioria das 26 entradas só se aplica sob configurações específicas, por isso a ferramenta as lista separadamente:

• 🔴 Afetado na configuração padrão — prioridade de tratamento (ex.: CVE-2026-43827 session fixation)
• ⚠️ Requer condições específicas — as condições são indicadas entrada por entrada; se não forem atendidas, não há acerto

Exemplos de condições (comparação literal com o texto original da descrição oficial, sem extrapolação):

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

🔴 A ferramenta não analisa sua configuração. O Shiro pode ser configurado em shiro.ini / application.yml / código Java, e uma conclusão derivada da análise seria mais perigosa do que não analisar. As condições são listadas explicitamente, para que você mesmo julgue — isto é um design intencional, não preguiça.

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

Capacidade de identificação: jar comum · Spring Boot fat jar (BOOT-INF/lib/) · WAR tradicional (WEB-INF/lib/) · uber jar (shiro-all, expandindo os módulos contidos) · jar renomeado (com base em pom.properties) · arquivos malformados com caminhos escritos usando barras invertidas.

Requer JDK 17+. Zero dependências em tempo de execução.

Como a tabela de decisão foi criada

Nem uma linha copiada manualmente. tools/gen_rules.py gera a partir de duas fontes primárias:

Fonte	O que fornece
shiro.apache.org/security-reports.html	Conjunto completo de entradas, texto original das descrições, texto original das condições de acionamento
GitHub Advisory API	Coordenadas do módulo afetado, intervalos de versão estruturados, classificação

O processo de geração inclui 12 asserções; se qualquer uma não for satisfeita, ele aborta sem gravar o arquivo (para evitar que "uma falha de análise gere uma tabela vazia e os testes continuem todos verdes"):

• Integridade: a contagem de CVEs pelos títulos h3 do corpo e pelos âncoras do sumário deve resultar no mesmo conjunto
• Rastreabilidade: os intervalos de versão preenchidos manualmente devem ter suas strings de versão aparecendo literalmente no texto oficial original
• Verificação empírica: a atribuição de módulo deve ser comprovada pela localização das classes no jar real (não se aceita "lembro que esta é do web")
• Executabilidade: cada versão de correção é consultada uma vez no Maven Central; as indisponíveis são sinalizadas
• Afirmações: o número de pontos cegos do Dependabot, as diferenças entre módulos e os módulos contidos no uber jar — todos devem continuar válidos

Antes da publicação há ainda tools/recheck_before_publish.py, que revalida os argumentos estruturais com um segundo conjunto independente de critérios (não importa o script de geração nem lê sua saída — reutilizar a mesma lógica de análise reproduziria os bugs junto).

Limitações

• Cobre apenas as 26 entradas da página oficial security-reports, sem incluir problemas não divulgados ou de integração de terceiros
• Os intervalos de versão vêm do oficial e do GitHub; quando há divergência ocasional entre os dois, prevalece o intervalo estruturado nas coordenadas do módulo
• Não analisa configurações, portanto entradas condicionais exigem que você mesmo julgue se são satisfeitas
• A tabela de decisão é um snapshot do momento da geração; o GitHub pode converter unreviewed em reviewed a qualquer momento

---

English