Un singolo jar, zero dipendenze runtime, completamente offline, Java 17+.

Perché esiste

1. Netty pubblica un solo numero di versione, ma ogni modulo ha la sua "fixed in"

Ogni modulo Netty viene rilasciato con lo stesso numero di versione, quindi l'aggiornamento sembra una decisione unica. Non lo è. Sulla linea 4.1 le versioni di fix per queste quattordici si distribuiscono su 125 / 129 / 132 / 133 / 135 / 136 / 137 — sette valori diversi. Segui un qualsiasi advisory e sei ancora dentro l'intervallo affetto degli altri.

2. Se hai risolto le CVE di HTTP/2, probabilmente sei ancora esposto qui

netty-codec-http2 dichiara netty-codec-http come dipendenza compile con <version>${project.version}</version> — le due versioni sono vincolate l'una all'altra.

Quindi, se sei passato a 4.1.136.Final perché è la versione che risolve le sette CVE di netty-codec-http2, ora esegui anche netty-codec-http 4.1.136.Final — e CVE-2026-59903 copre <= 4.1.136.Final. Ti serve 4.1.137.Final. Stessa storia sulla linea 4.2: la risposta per HTTP/2 è 4.2.16.Final, da questo lato serve 4.2.17.Final.

Non è un'affermazione che il consiglio su HTTP/2 fosse sbagliato — rispondeva per un modulo diverso. È un'affermazione che "un numero di versione" nasconde il fatto che stavi rispondendo per un solo modulo.

3. I limiti non sono scritti in modo coerente, e una versione ci si ribalta sopra

In questi quattordici advisory il limite superiore è scritto <= 16 volte e < 12 volte. La stessa 4.1.136.Final è quindi sicura per CVE-2026-56746 (< 4.1.136.Final) e affetta per CVE-2026-59903 (<= 4.1.136.Final).

Normalizzare l'operatore in un senso o nell'altro produce una risposta sbagliata — una direzione sovra-riporta, l'altra sotto-riporta, e sotto-riportare è l'errore costoso per uno strumento come questo. La tabella delle regole mantiene ogni operatore esattamente come scritto nell'advisory, e un'asserzione in tools/gen_rules.py fa fallire la build se quel caso limite smette mai di comportarsi così.

E non scansiona pom.xml — di proposito

Se usi Spring WebFlux, netty-codec-http 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

Codici di uscita: 0 = non affetto · 1 = affetto · 2 = impossibile giudicare.

🔴 2 non è deliberatamente 0. "Nessun risultato" e "pulito" non devono sembrare uguali a uno script. Un file che non è uno zip leggibile viene segnalato come errore di lettura, mai trattato silenziosamente come "nessun netty qui dentro".

Cosa non ti dice

• Solo queste 14 CVE, solo netty-codec-http. Gli altri moduli Netty hanno le proprie CVE; un risultato pulito qui non dice nulla su di esse. Se esegui anche netty-codec-http2, lo strumento lo segnala e indica il problema cross-modulo sopra, ma non giudica quel modulo.
• La severità è riportata come pubblicata. Due delle quattordici non hanno punteggio CVSS e una è low; vengono stampate così come sono, non aggregate in un totale spaventoso.
• Ognuno di questi advisory è reviewed con metadati di pacchetto completi, quindi Dependabot e simili li segnalano. Questo strumento non è "lo scanner non lo vede" — è "l'avviso ti dice un numero di versione per advisory, e devi comunque capire quale singola versione lo chiude."

Come è costruita la tabella delle regole

src/main/java/dev/mikko/nettyhttpcheck/RuleTable.java è generato, mai modificato a mano:

Sette asserzioni devono passare o non viene scritto nulla — tra queste: ogni advisory è ancora reviewed; entrambe le linee di versione sono presenti per ciascuno; l'intersezione calcolata è ancora 4.1.137.Final / 4.2.17.Final; quelle versioni sono effettivamente scaricabili da Maven Central (con una versione sentinella che deve dare 404, così una sonda rotta non può passare in silenzio); il caso limite del §3 si ribalta ancora; e la risposta HTTP/2 del §2 lascia ancora un buco da questo lato.

I controlli end-to-end con jar reali vivono in tools/e2e_real_jars.py — scaricano jar reali da Maven Central invece di fixture, perché "funziona su uno zip fatto a mano, fallisce sul jar reale" è una modalità di errore reale.

Licenza

MIT