Un seul jar, zéro dépendance d'exécution, entièrement hors ligne, Java 17+.

Pourquoi cet outil existe

1. Netty publie un seul numéro de version, mais chaque module a sa propre version « corrigée dans »

Chaque module Netty est publié sous le même numéro de version, donc la mise à niveau semble être une décision unique. Elle ne l'est pas. Sur la ligne 4.1, les versions de correctif pour ces quatorze se répartissent sur 125 / 129 / 132 / 133 / 135 / 136 / 137 — sept valeurs différentes. Suivez un seul avis et vous restez dans la plage affectée des autres.

2. Si vous avez corrigé les CVE HTTP/2, vous êtes probablement toujours exposé ici

netty-codec-http2 déclare netty-codec-http comme dépendance compile avec <version>${project.version}</version> — les deux versions sont verrouillées l'une à l'autre.

Donc, si vous êtes passé à 4.1.136.Final parce que c'est la version qui couvre les sept CVE de netty-codec-http2, vous exécutez désormais aussi netty-codec-http 4.1.136.Final — et CVE-2026-59903 couvre <= 4.1.136.Final. Vous avez besoin de 4.1.137.Final. Même histoire sur la ligne 4.2 : la réponse HTTP/2 est 4.2.16.Final, de ce côté il faut 4.2.17.Final.

Ce n'est pas une affirmation que le conseil HTTP/2 était faux — il répondait pour un module différent. C'est une affirmation que « un seul numéro de version » masque le fait que vous répondiez pour un seul module.

3. Les bornes ne sont pas écrites de manière cohérente, et une version bascule dessus

Sur ces quatorze avis, la borne supérieure est écrite <= 16 fois et < 12 fois. La même 4.1.136.Final est donc sûre pour CVE-2026-56746 (< 4.1.136.Final) et affectée pour CVE-2026-59903 (<= 4.1.136.Final).

Normaliser l'opérateur dans un sens ou dans l'autre produit une réponse erronée — une direction sur-signale, l'autre sous-signale, et la sous-signalisation est l'erreur coûteuse pour un outil comme celui-ci. La table de règles conserve chaque opérateur exactement comme l'avis l'a écrit, et une assertion dans tools/gen_rules.py fait échouer la compilation si ce cas limite cesse un jour de se comporter ainsi.

Et il ne scanne pas pom.xml — volontairement

Si vous utilisez Spring WebFlux, netty-codec-http arrive via

L'artifactId n'apparaît jamais dans votre pom.xml. Une vérification basée sur le pom répond « je ne l'utilise pas », ce qui est faux. Cet outil lit les jars qui sont réellement livrés.

Utilisation

Codes de sortie : 0 = non affecté · 1 = affecté · 2 = impossible de juger.

🔴 2 n'est volontairement pas 0. « Rien trouvé » et « propre » ne doivent pas se ressembler pour un script. Un fichier qui n'est pas un zip lisible est signalé comme une erreur de lecture, jamais traité silencieusement comme « pas de netty ici ».

Ce qu'il ne vous dit pas

• Uniquement ces 14 CVE, uniquement netty-codec-http. Les autres modules Netty ont leurs propres CVE ; un résultat propre ici ne dit rien à leur sujet. Si vous exécutez aussi netty-codec-http2, l'outil le signale et pointe vers le problème inter-modules ci-dessus, mais il ne juge pas ce module.
• La sévérité est rapportée telle que publiée. Deux des quatorze n'ont pas de score CVSS et une est low ; elles sont affichées telles quelles, non regroupées dans un total alarmiste.
• Chacun de ces avis est reviewed avec des métadonnées de package complètes, donc Dependabot et compagnie alertent bien dessus. Cet outil n'est pas « le scanner ne le voit pas » — c'est « l'alerte vous donne un numéro de version par avis, et vous devez encore déterminer quelle version unique y met fin. »

Comment la table de règles est construite

src/main/java/dev/mikko/nettyhttpcheck/RuleTable.java est généré, jamais édité à la main :

Sept assertions doivent passer ou rien n'est écrit — parmi elles : chaque avis est toujours reviewed ; les deux lignes de versions sont présentes pour chacun ; l'intersection calculée est toujours 4.1.137.Final / 4.2.17.Final ; ces versions sont réellement récupérables depuis Maven Central (avec une version sentinelle qui doit renvoyer 404, pour qu'une sonde cassée ne puisse pas passer silencieusement) ; le cas limite du §3 bascule toujours ; et la réponse HTTP/2 du §2 laisse toujours un trou de ce côté.

Les vérifications de bout en bout avec de vrais jars vivent dans tools/e2e_real_jars.py — elles téléchargent de vrais jars depuis Maven Central plutôt que des fixtures, car « fonctionne sur un zip fait main, échoue sur le vrai jar » est un vrai mode de défaillance.

Licence

MIT