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

Warum es das gibt

1. Netty liefert eine Versionsnummer, aber jedes Modul hat sein eigenes „behoben in“

Jedes Netty-Modul wird unter derselben Versionsnummer veröffentlicht, sodass sich ein Upgrade wie eine einzige Entscheidung anfühlt. Ist es aber nicht. In der 4.1-Linie liegen die Fix-Versionen für diese vierzehn bei 125 / 129 / 132 / 133 / 135 / 136 / 137 — sieben verschiedene Werte. Folgen Sie einem einzigen Advisory, befinden Sie sich immer noch im betroffenen Bereich der anderen.

2. Wenn Sie die HTTP/2-CVEs behoben haben, sind Sie hier wahrscheinlich weiterhin exponiert

netty-codec-http2 deklariert netty-codec-http als compile-Abhängigkeit mit <version>${project.version}</version> — die beiden Versionen sind aneinander gekoppelt.

Wenn Sie also auf 4.1.136.Final aktualisiert haben, weil das die Version ist, die die sieben netty-codec-http2-CVEs abdeckt, läuft bei Ihnen jetzt auch netty-codec-http 4.1.136.Final — und CVE-2026-59903 betrifft <= 4.1.136.Final. Sie benötigen 4.1.137.Final. Gleiche Geschichte in der 4.2-Linie: Die HTTP/2-Antwort ist 4.2.16.Final, diese Seite benötigt 4.2.17.Final.

Das ist keine Behauptung, dass die HTTP/2-Empfehlung falsch war — sie hat für ein anderes Modul geantwortet. Es ist die Behauptung, dass „eine Versionsnummer“ die Tatsache verschleiert, dass Sie nur für ein Modul geantwortet haben.

3. Grenzen sind nicht konsistent geschrieben, und eine Version kippt daran

Über diese vierzehn Advisories hinweg ist die Obergrenze 16-mal als <= und 12-mal als < geschrieben. Dieselbe 4.1.136.Final ist daher sicher für CVE-2026-56746 (< 4.1.136.Final) und betroffen für CVE-2026-59903 (<= 4.1.136.Final).

Den Operator in beide Richtungen zu normalisieren erzeugt eine falsche Antwort — die eine Richtung meldet zu viel, die andere zu wenig, und zu wenig zu melden ist der teure Fehler für ein solches Tool. Die Regel-Tabelle behält jeden Operator exakt so bei, wie das Advisory ihn geschrieben hat, und eine Assertion in tools/gen_rules.py lässt den Build fehlschlagen, falls dieser Grenzfall jemals aufhört, sich so zu verhalten.

Und es scannt pom.xml nicht — absichtlich

Wenn Sie Spring WebFlux verwenden, kommt netty-codec-http über

Der artifactId erscheint nie in Ihrer 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

Exit-Codes: 0 = nicht betroffen · 1 = betroffen · 2 = konnte nicht bewertet werden.

🔴 2 ist bewusst nicht 0. „Nichts gefunden“ und „sauber“ dürfen für ein Skript nicht gleich aussehen. Eine Datei, die kein lesbares Zip ist, wird als Lesefehler gemeldet, niemals stillschweigend als „kein netty hier drin“ behandelt.

Was es Ihnen nicht sagt

• Nur diese 14 CVEs, nur netty-codec-http. Andere Netty-Module haben ihre eigenen CVEs; ein sauberes Ergebnis hier sagt nichts über sie aus. Wenn Sie auch netty-codec-http2 ausführen, sagt das Tool das und weist auf das modulübergreifende Problem oben hin, bewertet dieses Modul aber nicht.
• Der Schweregrad wird wie veröffentlicht gemeldet. Zwei der vierzehn tragen keinen CVSS-Score und einer ist low; sie werden so ausgegeben, wie sie sind, nicht zu einer beängstigenden Gesamtsumme aufgerollt.
• Jedes dieser Advisories ist reviewed mit vollständigen Paket-Metadaten, sodass Dependabot und Co. tatsächlich darauf aufmerksam machen. Dieses Tool ist nicht „der Scanner kann es nicht sehen“ — es ist „die Warnung nennt Ihnen eine Versionsnummer pro Advisory, und Sie müssen trotzdem herausfinden, welche einzelne Version es beendet.“

Wie die Regel-Tabelle aufgebaut wird

src/main/java/dev/mikko/nettyhttpcheck/RuleTable.java ist generiert, niemals handbearbeitet:

Sieben Assertions müssen bestehen, sonst wird nichts geschrieben — darunter: jedes Advisory ist weiterhin reviewed; beide Versionslinien sind für jedes vorhanden; die berechnete Schnittmenge ist weiterhin 4.1.137.Final / 4.2.17.Final; diese Versionen sind tatsächlich von Maven Central abrufbar (mit einer Sentinel-Version, die 404 liefern muss, damit eine defekte Prüfung nicht stillschweigend bestehen kann); der Grenzfall aus §3 kippt weiterhin; und die HTTP/2-Antwort aus §2 hinterlässt auf dieser Seite weiterhin eine Lücke.

End-to-End-Prüfungen mit echten Jars befinden sich in tools/e2e_real_jars.py — sie laden echte Jars von Maven Central herunter statt Fixtures, weil „funktioniert mit handgebautem Zip, scheitert am echten Jar“ ein realer Fehlermodus ist.

Lizenz

MIT