Perché esiste

I sette advisory indicano ciascuno una versione di fix diversa. Sulla linea 4.1 sono 124 / 132 / 135 / 135 / 135 / 136 / 136. Segui un singolo advisory e sei comunque all'interno dell'intervallo affetto degli altri. La versione che risolve tutte e sette va calcolata — e non è scritta su nessuno di essi.

Lo stesso vale, con numeri completamente diversi, sulla linea 4.2 (4 / 11 / 15 / 15 / 15 / 16 / 16). Chi è fermo su 4.2.15.Final ha risolto cinque delle sette e spesso presume di essere "sulla nuova linea".

E non scansiona pom.xml — di proposito

Se usi Spring WebFlux, netty-codec-http2 arriva tramite

L'artifactId non compare mai nel tuo pom.xml. Un controllo basato sul pom risponde "non lo uso", il che è sbagliato. Questo strumento legge i jar che vengono realmente distribuiti.

Utilizzo

--utf8 / --gbk se l'output è illeggibile su console Windows.

Esempio:

Cosa non pretende

• Solo queste sette. Un output pulito non significa che Netty sia privo di problemi.
• Quattro delle sette sono medium. Solo CVE-2025-55163, CVE-2026-33871 e CVE-2026-56819 sono classificate high. Lo strumento stampa ogni severità separatamente e dovresti fare lo stesso.
• Non fa mai supposizioni. Una versione non analizzabile, una linea di rilascio sconosciuta (4.0, 5.0), un archivio illeggibile — tutto viene segnalato come impossibile giudicare, mai come sicuro.
• grpc-netty-shaded viene rilevato, ma solo CVE-2025-55163 elenca quella coordinata. "L'advisory non la elenca" non significa "non è affetta".

Una stranezza onesta, messa in luce anziché nascosta

CVE-2026-33871 sulla linea 4.2: l'intervallo affetto è < 4.2.10.Final, ma il fix dichiarato è 4.2.11.Final. 4.2.10 cade tra i due — fuori dall'intervallo, sotto il fix. Lo strumento lo segnala esplicitamente invece di lasciarlo cadere nel ramo predefinito, che è "sicuro".

La tabella delle regole è generata, non scritta a mano

tools/gen_rules.py costruisce RuleTable.java direttamente dagli advisory GitHub e rifiuta di emettere qualsiasi cosa a meno che cinque asserzioni non siano verificate — inclusa quella che l'intersezione calcolata sia davvero 4.1.136.Final / 4.2.16.Final, e che queste esistano su Maven Central mentre una versione sentinella restituisce 404.

tools/recheck_before_publish.py riverifica le affermazioni portanti tramite fonti deliberatamente non correlate: NVD (non OSV — i suoi dati Maven rispecchiano GHSA), Maven Central e il bytecode dei jar reali. Il controllo del bytecode è bidirezionale: il marcatore di fix deve essere presente in 4.1.136 e assente in 4.1.135. Questa seconda metà ha individuato un controllo errato al primo tentativo.

Build

Licenza

MIT