Jar unique, zéro dépendance à l'exécution, entièrement hors ligne, Java 17+.

Pourquoi cet outil existe

Les sept avis nomment chacun une version de correctif différente. Sur la ligne 4.1, ce sont 124 / 132 / 135 / 135 / 135 / 136 / 136. Suivez un seul avis et vous restez dans la plage affectée des autres. La version qui couvre les sept doit être calculée — et elle n'est écrite sur aucun d'entre eux.

Il en va de même, avec des numéros entièrement différents, sur la ligne 4.2 (4 / 11 / 15 / 15 / 15 / 16 / 16). Ceux qui sont sur 4.2.15.Final ont corrigé cinq des sept et supposent souvent être « sur la nouvelle ligne ».

Et il ne scanne pas pom.xml — volontairement

Si vous utilisez Spring WebFlux, netty-codec-http2 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 réellement livrés.

Utilisation

--utf8 / --gbk si la sortie est illisible sur une console Windows.

Exemple :

Ce qu'il ne prétend pas

• Uniquement ces sept. Une sortie propre ne signifie pas que Netty est sans problème.
• Quatre des sept sont medium. Seules CVE-2025-55163, CVE-2026-33871 et CVE-2026-56819 sont classées high. L'outil affiche chaque sévérité séparément, et vous devriez faire de même.
• Il ne devine jamais. Une version non analysable, une ligne de version inconnue (4.0, 5.0), une archive illisible — tout est signalé comme impossible à juger, jamais comme sûr.
• grpc-netty-shaded est détecté, mais seule CVE-2025-55163 liste cette coordonnée. « L'avis ne la liste pas » n'est pas « elle n'est pas affectée ».

Une bizarrerie honnête, mise en évidence plutôt que cachée

CVE-2026-33871 sur la ligne 4.2 : la plage affectée est < 4.2.10.Final, mais le correctif indiqué est 4.2.11.Final. 4.2.10 se situe entre les deux — hors de la plage, en dessous du correctif. L'outil le signale explicitement au lieu de le laisser tomber dans la branche par défaut, qui est « sûr ».

Le tableau des règles est généré, pas saisi

tools/gen_rules.py construit RuleTable.java directement à partir des avis GitHub et refuse de générer quoi que ce soit à moins que cinq assertions ne soient vérifiées — y compris que l'intersection calculée soit bien 4.1.136.Final / 4.2.16.Final, et que celles-ci existent sur Maven Central tandis qu'une version sentinelle renvoie une 404.

tools/recheck_before_publish.py re-vérifie les affirmations porteuses via des sources délibérément indépendantes : NVD (pas OSV — ses données Maven reflètent GHSA), Maven Central, et le bytecode des vrais jars. La vérification du bytecode est bidirectionnelle : le marqueur de correctif doit être présent dans 4.1.136 et absent dans 4.1.135. Cette seconde moitié a détecté une mauvaise vérification lors du premier passage.

Construction

Licence

MIT