Einzelnes Jar, keine Laufzeitabhängigkeiten, vollständig offline, Java 17+.

Warum es das gibt

Die sieben Advisories nennen jeweils eine andere Fix-Version. In der 4.1-Linie sind das 124 / 132 / 135 / 135 / 135 / 136 / 136. Folgst du einem einzelnen Advisory, befindest du dich weiterhin im betroffenen Bereich der anderen. Die Version, die alle sieben abdeckt, muss berechnet werden — und steht auf keinem von ihnen.

Dasselbe gilt, mit völlig anderen Zahlen, für die 4.2-Linie (4 / 11 / 15 / 15 / 15 / 16 / 16). Wer auf 4.2.15.Final sitzt, hat fünf der sieben behoben und nimmt oft an, er sei „auf der neuen Linie".

Und es scannt pom.xml nicht — absichtlich

Wenn du Spring WebFlux verwendest, kommt netty-codec-http2 über

Die artifactId erscheint nie in deiner pom.xml. Eine pom-basierte Prüfung antwortet „Ich verwende es nicht", was falsch ist. Dieses Tool liest die Jars, die tatsächlich ausgeliefert werden.

Verwendung

--utf8 / --gbk, falls die Ausgabe auf einer Windows-Konsole als Mojibake erscheint.

Beispiel:

Was es nicht behauptet

• Nur diese sieben. Eine saubere Ausgabe bedeutet nicht, dass Netty problemfrei ist.
• Vier der sieben sind medium. Nur CVE-2025-55163, CVE-2026-33871 und CVE-2026-56819 sind als high eingestuft. Das Tool druckt jede Schwere separat — und du solltest es auch tun.
• Es rät nie. Eine nicht parsebare Version, eine unbekannte Release-Linie (4.0, 5.0), ein nicht lesbares Archiv — alles wird als kann nicht beurteilt werden gemeldet, nie als sicher.
• grpc-netty-shaded wird erkannt, aber nur CVE-2025-55163 listet diese Koordinate. „Das Advisory listet es nicht" ist nicht „es ist nicht betroffen".

Eine ehrliche Besonderheit, offengelegt statt versteckt

CVE-2026-33871 in der 4.2-Linie: Der betroffene Bereich ist < 4.2.10.Final, aber der angegebene Fix ist 4.2.11.Final. 4.2.10 liegt dazwischen — außerhalb des Bereichs, unterhalb des Fixes. Das Tool meldet dies explizit, statt es in den Standard-Zweig fallen zu lassen, der „sicher" wäre.

Die Regel-Tabelle ist generiert, nicht getippt

tools/gen_rules.py erstellt RuleTable.java direkt aus den GitHub-Advisories und weigert sich, etwas auszugeben, es sei denn, fünf Annahmen gelten — einschließlich, dass die berechnete Schnittmenge wirklich 4.1.136.Final / 4.2.16.Final ist und dass diese auf Maven Central existieren, während eine Sentinel-Version 404 liefert.

tools/recheck_before_publish.py verifiziert die tragenden Behauptungen erneut über bewusst unabhängige Quellen: NVD (nicht OSV — dessen Maven-Daten spiegeln GHSA), Maven Central und den Bytecode der echten Jars. Der Bytecode-Check ist bidirektional: Das Fix-Marker muss in 4.1.136 vorhanden sein und in 4.1.135 fehlen. Diese zweite Hälfte hat beim ersten Lauf einen fehlerhaften Check aufgedeckt.

Build

Lizenz

MIT