Um único jar, zero dependências em tempo de execução, totalmente offline, Java 17+.

Por que isto existe

1. O Netty publica um único número de versão, mas cada módulo tem seu próprio "corrigido em"

Cada módulo do Netty é lançado sob o mesmo número de versão, então atualizar parece uma decisão única. Não é. Na linha 4.1, as versões de correção para estes catorze caem em 125 / 129 / 132 / 133 / 135 / 136 / 137 — sete valores diferentes. Siga qualquer um dos avisos e você ainda estará dentro da faixa afetada dos demais.

2. Se você corrigiu os CVEs de HTTP/2, provavelmente ainda está exposto aqui

O netty-codec-http2 declara netty-codec-http como dependência compile com <version>${project.version}</version> — as duas versões estão fixadas uma à outra.

Então, se você atualizou para 4.1.136.Final porque essa é a versão que resolve os sete CVEs do netty-codec-http2, agora você executa também o netty-codec-http 4.1.136.Final — e o CVE-2026-59903 cobre <= 4.1.136.Final. Você precisa do 4.1.137.Final. Mesma história na linha 4.2: a resposta para HTTP/2 é 4.2.16.Final, este lado precisa de 4.2.17.Final.

Isto não é uma afirmação de que a orientação sobre HTTP/2 estava errada — ela respondia por um módulo diferente. É uma afirmação de que "um número de versão" esconde o fato de que você estava respondendo por apenas um módulo.

3. Os limites não são escritos de forma consistente, e uma versão depende disso

Nestes catorze avisos, o limite superior é escrito como <= 16 vezes e < 12 vezes. O mesmo 4.1.136.Final é, portanto, seguro para o CVE-2026-56746 (< 4.1.136.Final) e afetado para o CVE-2026-59903 (<= 4.1.136.Final).

Normalizar o operador em qualquer direção produz uma resposta errada — uma direção supernotifica, a outra subnotifica, e subnotificar é o erro caro para uma ferramenta como esta. A tabela de regras mantém cada operador exatamente como o aviso o escreveu, e uma asserção em tools/gen_rules.py falha o build se esse caso de limite deixar de se comportar dessa forma.

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

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

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

Uso

Códigos de saída: 0 = não afetado · 1 = afetado · 2 = não foi possível avaliar.

🔴 2 deliberadamente não é 0. "Nada encontrado" e "limpo" não devem parecer iguais para um script. Um arquivo que não é um zip legível é relatado como falha de leitura, nunca tratado silenciosamente como "sem netty aqui".

O que ela não informa

• Apenas estes 14 CVEs, apenas netty-codec-http. Outros módulos do Netty têm seus próprios CVEs; um resultado limpo aqui não diz nada sobre eles. Se você também executa o netty-codec-http2, a ferramenta informa isso e aponta para o problema entre módulos acima, mas não avalia esse módulo.
• A severidade é relatada como publicada. Dois dos catorze não possuem pontuação CVSS e um é baixa; eles são impressos como estão, não agrupados em um total assustador.
• Cada um desses avisos está revisado com metadados completos do pacote, então o Dependabot e afins realmente alertam sobre eles. Esta ferramenta não é "o scanner não consegue ver" — é "o alerta informa um número de versão por aviso, e você ainda precisa descobrir qual versão única encerra isso."

Como a tabela de regras é construída

src/main/java/dev/mikko/nettyhttpcheck/RuleTable.java é gerado, nunca editado manualmente:

Sete asserções devem passar ou nada é gravado — entre elas: cada aviso ainda está revisado; ambas as linhas de versão estão presentes para cada um; a interseção calculada ainda é 4.1.137.Final / 4.2.17.Final; essas versões são realmente buscáveis no Maven Central (com uma versão sentinela que deve retornar 404, para que uma sonda quebrada não passe silenciosamente); o caso de limite na §3 ainda se inverte; e a resposta de HTTP/2 da §2 ainda deixa uma lacuna neste lado.

Verificações ponta a ponta com jars reais ficam em tools/e2e_real_jars.py — elas baixam jars reais do Maven Central em vez de fixtures, porque "funciona em um zip feito à mão, falha no jar real" é um modo real de falha.

Licença

MIT