shiro-check

Descobre os módulos e versões reais do Apache Shiro que você instalou e determina, uma a uma, quais das 26 CVEs oficiais realmente se aplicam a você.

Um único jar sem dependências, sem internet, não lê seu pom — analisa diretamente os artefatos de build (jar / war / fat jar / diretório).

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

Por que não basta olhar para o número da versão

As CVEs do Shiro não estão ligadas ao «Shiro», e sim a módulos específicos. O mesmo número significa regras diferentes em módulos diferentes:

Das 26 oficiais, 13 não tocam em shiro-core de forma alguma. Comprimi-las em uma frase como «Shiro < 1.7.1 tem vulnerabilidades» é fazer pelo usuário o julgamento que ele deveria fazer sozinho — e fazê-lo de forma errada.

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

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

1. 5 entradas não chegam aos alertas do Dependabot

O Dependabot faz a correspondência das advisories do GitHub pelas coordenadas de dependência. Das 26, 5 não batem certo:

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

ℹ️ unreviewed é um estado normal do fluxo do GitHub (importado automaticamente pelo NVD, ainda sem marcação manual dos pacotes afetados); a correspondência por coordenadas também é um design razoável. Aqui apenas se constata o fato de «não entrar nos alertas» — não se diz que alguém reportou errado.

2. O uber jar esconde outros módulos dentro dele

shiro-all é um uber jar que empacota vários módulos. Na prática, dentro de shiro-all-1.3.2.jar há 6 arquivos 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 cujo pom declara apenas shiro-all tem apenas um nome no nível das coordenadas (das 26, só a CVE-2016-6802 está associada a essa coordenada), mas dentro do jar há de fato código dos três módulos core / web / spring.

Analisar o artefato real enxerga através dessa camada. Em um teste com shiro-all-1.3.2.jar, a ferramenta reportou 20 entradas em 3 módulos.

3. As versões oficiais de correção de 3 delas não estão disponíveis no Maven Central

O first_patched_version de 3 advisories é 3.0.0-alpha-2, mas essa versão nunca foi publicada no Maven Central (a oficial lançou direto a versão final 3.0.0). Atualizar seguindo essa referência é impossível — a ferramenta sinaliza isso e troca a sugestão de atualização por uma versão que realmente pode ser obtida.

A detecção não significa «você está afetado»

«Hit» = o módulo está presente E a versão está dentro do intervalo afetado oficial. Não equivale a «já explorado» nem a «necessariamente explorável».

A grande maioria das 26 entradas só se aplica com configuração específica, por isso a ferramenta as lista separadamente:

• 🔴 Afetado já na configuração padrão — tratar com prioridade (ex.: CVE-2026-43827 session fixation)
• ⚠️ Requer condições específicas — as condições são apresentadas uma a uma; se não forem satisfeitas, não é hit

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

CVE-2026-49268  apenas ao usar DefaultLdapRealm (nome de usuário concatenado no DN do LDAP sem escape)
CVE-2023-22602  apenas ao usar com Spring Boot 2.6+, sem redefinir
                spring.mvc.pathmatch.matching-strategy para ant_path_matcher
CVE-2026-23903  apenas quando arquivos estáticos estão em um sistema de arquivos que não diferencia
                maiúsculas de minúsculas (ex.: configuração padrão do macOS), e no Shiro só estão
                configurados caminhos de filter em minúsculas; afeta apenas arquivos estáticos

🔴 A ferramenta não analisa sua configuração. O Shiro pode ser configurado em shiro.ini / application.yml / código Java; uma conclusão obtida com parsing seria mais perigosa do que não analisar. As condições estão listadas em texto claro para você mesmo julgar — é uma decisão deliberada, não preguiça.

Uso

# analisa um jar / war
java -jar shiro-check.jar your-app.jar

# analisa um diretório inteiro (recursivo)
java -jar shiro-check.jar /path/to/libs

# também lista as entradas «não aplicáveis»
java -jar shiro-check.jar --all your-app.jar

# para quando o console do Windows exibe caracteres chineses corrompidos
java -jar shiro-check.jar --utf8 your-app.jar

Capacidade de reconhecimento: jar comum · Spring Boot fat jar (BOOT-INF/lib/) · WAR tradicional (WEB-INF/lib/) · uber jar (shiro-all, expande os módulos internos) · jar renomeado (a referência é o pom.properties) · arquivos malformados que usam barras invertidas nos caminhos.

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

De onde vem a tabela de avaliação

Nenhuma linha é escrita à mão. tools/gen_rules.py gera a partir de duas fontes primárias:

O processo de geração tem 12 asserções; se qualquer uma não for satisfeita, ele aborta sem gravar o arquivo (evitando «falha de parsing gera tabela oca e os testes continuam todos verdes»):

• Integridade: a contagem pelos critérios dos h3 do corpo e da âncora do sumário precisa resultar no mesmo conjunto de CVEs
• Rastreabilidade: as strings de versão dos intervalos preenchidos manualmente precisam aparecer literalmente no texto oficial
• Verificação real: a atribuição de módulos precisa ser comprovada pelas posições das classes em jars reais (não se aceita «eu lembro que esta é do web»)
• Executável: cada versão de correção é verificada no Maven Central; as indisponíveis são sinalizadas
• Afirmações: a quantidade de lacunas do Dependabot, as diferenças entre módulos e os módulos contidos no uber jar — tudo precisa continuar válido

Antes da publicação, existe tools/recheck_before_publish.py, que revalida os argumentos estruturais com um segundo critério independente (não importa o script de geração nem lê a saída dele — reutilizar a mesma lógica de parsing reproduziria os bugs junto).

Limitações

• Cobre apenas as 26 entradas da página oficial de security-reports; não inclui problemas não divulgados nem de integrações de terceiros
• Os intervalos de versão vêm do oficial e do GitHub; quando os critérios divergem ocasionalmente, prevalece o intervalo estruturado nas coordenadas do módulo
• Não analisa configuração; portanto, as entradas condicionais exigem que você mesmo julgue se são atendidas
• A tabela de avaliação é um instantâneo do momento da geração; o GitHub pode mudar unreviewed para reviewed a qualquer momento

Inglês

shiro-check analisa seus artefatos de build (jar / war / fat jar / diretório) para identificar quais módulos do Apache Shiro você realmente distribui e, em seguida, avalia todas as 26 CVEs oficiais contra sua combinação exata de módulo + versão.

Por que ela existe: as CVEs do Shiro estão ligadas a módulos, não ao «Shiro». 13 das 26 nunca tocam em shiro-core de forma alguma. A ferramenta trabalha na granularidade de CVE × módulo (37 regras, 7 módulos).

Três coisas que a correspondência baseada em coordenadas não consegue ver:

1. 5 entradas nunca chegam aos alertas do Dependabot — 3 advisories ainda estão unreviewed, com a lista de pacotes afetados vazia; 2 estão associadas apenas a org.apache.shiro:shiro-root, que é um POM pai com packaging=pom e sem jar no Maven Central (HTTP 404), portanto nenhum projeto depende dele.
2. shiro-all é um uber jar — shiro-all-1.3.2.jar contém 6 entradas pom.properties (core, web, spring, ehcache, quartz + ele mesmo). Seu pom mostra uma coordenada; o jar carrega código de três módulos.
3. 3 advisories apontam 3.0.0-alpha-2 como a correção, uma versão nunca publicada no Maven Central. A ferramenta sinaliza essas e sugere uma versão para a qual você pode de fato atualizar.

Um «hit» significa módulo presente E versão dentro do intervalo afetado oficial. Não significa explorável — a maioria das entradas exige configuração específica, que a ferramenta lista literalmente a partir da advisory oficial. Deliberadamente, ela não analisa sua configuração.

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

Requer JDK 17+. Sem dependências em tempo de execução. A tabela de regras é gerada a partir de duas fontes primárias com 12 asserções que abortam em caso de falha; veja tools/gen_rules.py.

Licença

Apache License 2.0