Essas 14, o que você vê em cada um dos três lugares é:

O único lugar que documenta isso por completo é o registro original que a Apache submeteu como CNA no CVE.org — ou seja, a camada que menos gente vai fuçar. O que esta ferramenta faz é confrontar a informação dessa camada com a versão realmente instalada na sua máquina.

🔴 Esta ferramenta expõe diferenças entre fontes de dados, não o comportamento de um produto. "Seu scanner vai reportar essas 10 ou não" depende de qual base ele lê e como ele mescla — isso não foi testado na prática, então não está escrito aqui.

A outra metade igualmente importante: das 14, apenas 2 afetam a configuração padrão

Reportar só pelo número da versão faz com que 12 itens que "só valem com configuração específica" também pareçam "você está afetado" — isso é mandar você fazer algo desnecessário.

Por isso, quando um diretório de instalação é informado, a ferramenta lê todos os XMLs em conf/ (incluindo conf/Catalina/<host>/), remove os blocos de comentário e então procura os marcadores das condições de disparo. Remover comentários não é opcional: no server.xml oficial, a busca por texto de UpgradeProtocol encontra 1 ocorrência; sem comentários, são 0 — o trecho inteiro está comentado.

Rodando numa instalação limpa do 8.5.100 oficial, o resultado é:

Ativando HTTP/2, RewriteValve e CGIServlet na mesma configuração, "confirmados por configuração" passa para 5.

Uso

Como a versão é identificada em instalações descompactadas

Os jars em lib/ não têm nenhum número de versão no nome do arquivo (é catalina.jar, não catalina-8.5.100.jar). Ferramentas que extraem a versão só pelo nome do arquivo não reconhecem nada nesse tipo de implantação — e "não escaneou nada" parece exatamente igual a "você está seguro".

Esta ferramenta obtém a versão nesta ordem:

1. server.number em catalina.jar!/org/apache/catalina/util/ServerInfo.properties — é o que o próprio version.sh do Tomcat reporta
2. Implementation-Version no META-INF/MANIFEST.MF
3. Nome do arquivo (só existe em formatos como o embutido do Spring Boot)

Quando as duas fontes divergem (ServerInfo.properties pode ser sobrescrito, algo comum para esconder a versão), as duas são reportadas, sem escolher por você.

Três linhas que não serão cruzadas

Um: dá para confirmar que está ativo, não dá para confirmar que está inativo. Quando o relatório diz "não encontrado", significa "não encontrado nos arquivos que examinei", não "você não ativou". A configuração pode estar em lugares que a ferramenta não enxerga: WEB-INF/web.xml dentro do war, CATALINA_BASE externo, argumentos de inicialização. Por isso não existe a categoria "não afetado" — tudo o que não é encontrado cai em exige confirmação manual.

Dois: encontrar o marcador também não significa que é exatamente aquilo. Por exemplo, no server.xml padrão oficial o AprLifecycleListener já vem ativado, mas ele apenas tenta carregar a biblioteca nativa — se a biblioteca não existe, o conector APR não é ativado. Então é um "marcador fraco": quando há correspondência, reporta-se apenas "possível", não "confirmado".

Três: não existe versão 8.5 para a qual atualizar. O first_patched_version das 14 é null do lado do 8.5. Não é "ainda não corrigido", é "não será corrigido para o 8.5". A única saída é mudar de linha (9.0 / 10.1 / 11.0). Esta ferramenta responde "do que você está afetado", sem fingir que pode responder "para qual 8.5 atualizar".

Outra coisa que pode fazer você achar que "a ferramenta está errada": o mesmo CVE tem várias classificações

Tomando o CVE-2025-55754 como exemplo, os quatro números são todos verdadeiros:

Se você olhar só o NVD, vai achar que é o mais grave de todos; só a Apache, vai achar que pode ignorar. Nenhum dos dois está errado — a Apache avalia a explorabilidade real na configuração padrão; o CVSS é um cálculo mecânico a partir do vetor, sem considerar se você ativou ou não o recurso.

Por isso esta ferramenta imprime os quatro números e, quando as duas avaliações divergem, diz isso explicitamente.

Os dois vocabulários não são a mesma coisa; o alinhamento só é feito no passo que a Apache suporta oficialmente

A Apache usa low / moderate / important / critical; o GitHub usa low / medium / high / critical. A base do alinhamento vem do texto oficial em security-impact.html do Tomcat:

Important / High — A vulnerability rated as Important (or High) impact is one which could result in the compromise of data or availability of the server.

→ Important e High são dois nomes para o mesmo nível, e isso está escrito junto pela própria Apache. 🔴 Já a Apache não diz que moderate e medium são alinháveis, e esta ferramenta também não alinha por conta própria — o Moderate da ASF define condições de explorabilidade como "tem fatores de mitigação significativos / não afeta configurações comuns / exige autenticação", enquanto o medium do GitHub é uma faixa de pontuação CVSS; não são a mesma coisa. Nesse caso, reporta-se "a Apache não diz que esses dois níveis são iguais" e os dois são apresentados.

Sob esse critério, das 14, 5 têm avaliações substancialmente diferentes entre os dois lados (o caso mais extremo é o CVE-2025-52520: Apache low / GitHub high), 2 não são alinháveis e 7 são iguais.

De onde vêm os dados e como reproduzir

A tabela de decisão CveTable.java é gerada, sem nenhuma linha copiada à mão:

Antes de publicar/divulgar, ainda é feita uma verificação com critério independente — ela não lê o sources.json acima, mas analisa o CveTable.java gerado e consulta o NVD novamente pelo cpe:

Esse passo não é formalidade: na primeira execução, ele pegou um erro real. O script gerador, ao julgar se "o NVD tem o 8.5", só reconhecia "intervalo cujo limite inferior começa com 8.5", mas o CVE-2025-24813 está escrito como versionStartIncluding=None .. versionEndExcluding=9.0.99 — limite inferior aberto, ou seja, ele cobre o 8.5. A diferença ficou com uma entrada a mais. Consultar cveId por item nunca teria revelado isso; só o critério na perspectiva do usuário — "consultar 8.5.100 pelo cpe" — foi que esbarrou no problema.

Build

Requer JDK 17+. Zero dependências em tempo de execução; JUnit apenas nos testes.

License

MIT — veja LICENSE