Ou seja, toda a linha 3.0 está incluída, e a lista versão por versão vai de 3.0.15.RELEASE até 1.0.0. E no Maven Central, a linha 3.0 termina em 3.0.15.RELEASE, sem nenhum lançamento posterior:

As versões corrigidas das duas CVEs estão na linha 3.1. Portanto, usuários de 3.0.x não têm a opção de "mudar o número da versão" — só resta migrar entre linhas de versão principais — e 3.1 é uma mudança disruptiva listada oficialmente (trechos copiados da seção 3.1.0.M1 do ChangeLog.txt oficial):

Templates que usaram ${#request.…} / ${#session.…} vão falhar diretamente após a atualização; esses valores precisarão ser passados pelo Controller via Model. Isso é uma migração que precisa ser agendada, não uma simples mudança de versão.

Quem está nessa linha

Contagem de dependências do deps.dev (lido diretamente em 2026-09-04, qualquer pessoa pode recalcular):

A versão individual com a maior base de instalação é 3.0.11.RELEASE, 36% maior que a 3.1.3, a mais alta da linha 3.1, e ela não tem saída dentro da própria linha.

Uso

Códigos de saída: 2 = há um artefato cuja linha de versão não tem correção na mesma linha · 1 = afetado, mas com correção na mesma linha / não foi possível determinar · 0 = nada encontrado · 3 = erro de uso ou de caminho. Pode ser integrado diretamente ao CI.

O que verificar com mais precisão

Verifique os artefatos de build (target/*.jar, *.war), não os diretórios de código-fonte. O Thymeleaf é, na grande maioria dos casos, introduzido de forma transitiva pelo spring-boot-starter-thymeleaf, e o starter não define versão — a versão do Thymeleaf simplesmente não aparece no pom. Nesse caso, a ferramenta dirá explicitamente "não foi possível determinar pelo pom", em vez de tratá-lo como inexistente.

Três critérios de identificação, ordenados por confiabilidade:

1. Implementation-Version do MANIFEST — reconhece o jar mesmo se ele foi renomeado por ferramentas de repacotamento. (O jar oficial do Thymeleaf tem apenas MANIFEST.MF em META-INF/, sem diretório maven/, então este é o critério mais forte para ele.)
2. Metadados Maven pom.properties
3. Nome do arquivo jar

Os diretórios BOOT-INF/lib/ e WEB-INF/lib/ dentro de fat jars / wars são desmembrados e examinados um a um, e o MANIFEST de jars embutidos também é lido.

As duas CVEs são dois mecanismos diferentes

O escopo afetado da segunda inclui a 3.1.4, então quem atualizou para 3.1.4 seguindo a primeira advisory cai dentro da segunda.

Mas não leia isso como "a correção oficial não foi completa" — as duas advisories descrevem mecanismos diferentes, e as versões oficiais 3.1.4 (2026-04-12) e 3.1.5 (2026-04-21) têm nove dias de diferença, sem nenhum texto oficial dizendo que a correção anterior era incompleta. Esta ferramenta apenas apresenta os fatos lado a lado, sem tirar essa conclusão por você.

De onde vem a tabela de verificação e como conferir se ela ainda está correta

Cada número em RuleTable.java pode ser verificado retroativamente:

Ele cruza a tabela de verificação com duas fontes primárias — os intervalos afetados e a lista versão por versão do OSV, e o maven-metadata.xml do Maven Central — e, se houver divergência, sai com código de saída diferente de zero.

Três convenções:

• Se não conseguir obter os dados, sai com código 2, reportando "não foi possível verificar", não "verificação aprovada". Se a rede cair, não é para ler como "tudo certo".
• Apenas verifica, não altera o código automaticamente. Se os números mudarem, é preciso que uma pessoa analise como mudaram.
• Ele monitora especificamente duas coisas que podem tornar esta ferramenta obsoleta:se a 3.1.6 foi lançada e se a linha 3.0 ganhou de repente uma 3.0.16.

Build

A ausência de dependências em tempo de execução é intencional: uma ferramenta de verificação precisa poder ser jogada em qualquer ambiente e executada diretamente.

License

Apache-2.0