Por que isto existe

Os sete avisos indicam cada um uma versão de correção diferente. Na linha 4.1, elas são 124 / 132 / 135 / 135 / 135 / 136 / 136. Siga qualquer aviso individual e você ainda estará dentro do intervalo afetado dos demais. A versão que elimina todas as sete precisa ser calculada — e não está escrita em nenhuma delas.

O mesmo vale, com números totalmente diferentes, na linha 4.2 (4 / 11 / 15 / 15 / 15 / 16 / 16). Quem está em 4.2.15.Final corrigiu cinco das sete e muitas vezes assume que está "na nova linha".

E não verifica o pom.xml — de propósito

Se você usa Spring WebFlux, o netty-codec-http2 chega por meio de

O artifactId nunca aparece no seu pom.xml. Uma verificação baseada no pom responde "não uso", o que está errado. Esta ferramenta lê os jars que realmente são enviados.

Uso

--utf8 / --gbk se a saída aparecer ilegível em um console Windows.

Exemplo:

O que não afirma

• Apenas estas sete. Uma saída limpa não significa que o Netty está livre de problemas.
• Quatro das sete são medium. Apenas CVE-2025-55163, CVE-2026-33871 e CVE-2026-56819 são classificadas como high. A ferramenta imprime cada severidade separadamente — e você também deveria.
• Nunca adivinha. Uma versão não analisável, uma linha de lançamento desconhecida (4.0, 5.0), um arquivo ilegível — tudo é reportado como não é possível julgar, nunca como seguro.
• grpc-netty-shaded é detectado, mas apenas CVE-2025-55163 lista essa coordenada. "O aviso não a lista" não significa "não está afetado".

Uma peculiaridade honesta, exposta em vez de oculta

CVE-2026-33871 na linha 4.2: o intervalo afetado é < 4.2.10.Final, mas a correção declarada é 4.2.11.Final. 4.2.10 fica entre eles — fora do intervalo, abaixo da correção. A ferramenta reporta isso explicitamente em vez de deixar cair no ramo padrão, que é "seguro".

A tabela de regras é gerada, não digitada

tools/gen_rules.py constrói o RuleTable.java diretamente dos avisos do GitHub e se recusa a emitir qualquer coisa a menos que cinco asserções sejam válidas — incluindo que a interseção calculada realmente seja 4.1.136.Final / 4.2.16.Final, e que essas existam no Maven Central enquanto uma versão sentinela retorna 404.

tools/recheck_before_publish.py reverifica as afirmações estruturais por meio de fontes deliberadamente não relacionadas: NVD (não OSV — seus dados Maven espelham o GHSA), Maven Central e o bytecode dos jars reais. A verificação de bytecode é bidirecional: o marcador de correção deve estar presente em 4.1.136 e ausente em 4.1.135. Essa segunda metade pegou uma verificação ruim na primeira execução.

Build

Licença

MIT