jetty-line-check

Welche der sechs CVEs aus dem Jahr 2026 betreffen Ihre Jetty-Installation (oder das Jetty, das über Spring Boot hereinkommt) – und existiert die Version, auf die das offizielle Team Sie upgraden lässt, überhaupt auf Maven Central?

Im Fokus steht CVE-2026-2332 (GHSA-355h-qmc2-wpwf, high / CVSS v3 7.4): Chunked-Request-Schmuggel in jetty-http. Am 2026-09-17 hat das offizielle Team zudem die verwandte CVE-2026-19203 veröffentlicht (LF EXT.TERM-Schmuggel, high / CVSS v4 8.3): Ihre 9.4-Linie ist bis 9.4.63 betroffen, das offizielle Team lässt Sie auf 9.4.64 upgraden – und 9.4.64 ist auf Central ebenfalls 404. Die härteste Tatsache: Für die drei EOL-Altlinien 9.4 / 10 / 11 existieren die öffentlich zugänglichen Fix-Versionen schlicht nicht – die offizielle Sicherheitsseite schreibt zu jeder von ihnen see details for availability (= kommerzieller Support), und diese Versionsnummern liefern bei tatsächlichen Tests auf Maven Central allesamt 404.

java -jar jetty-line-check.jar /path/to/jetty         # 解压部署的 Jetty(扫 lib/*.jar)
java -jar jetty-line-check.jar app.war                # war
java -jar jetty-line-check.jar app.jar                # Spring Boot fat jar
java -jar jetty-line-check.jar --table                # 只看六条 CVE × 模块 × 版本线的判定表
java -jar jetty-line-check.jar --utf8 ...             # Windows 控制台中文乱码时加

Kriterium: Koordinaten + Versionslinie → Entscheidungstabelle + Central-Echt-JAR-Probe

Das Schwesterprojekt tomcat-line-check verwendet als Kriterium „ob im JAR eine bestimmte Fix-Klasse vorhanden ist“, weil jener Tomcat-Fix eine neue Klasse hinzugefügt hat.

Bei diesen Jetty-Einträgen funktioniert das nicht. Die zentrale CVE-2026-2332 – ihr Fix ändert den Methodenrumpf von HttpParser und fügt keine neue Klasse hinzu (vor dem Bau mit gh api compare + javap belegt). Das Kriterium kann also nur lauten:

Welche CVEs deine vollständigen Koordinaten + Versionslinie treffen; und ob die offiziell benannte Fix-Version auf Maven Central tatsächlich existiert.

Die Entscheidungstabelle wird von tools/gen_table.py aus den vulnerabilities[] der sechs GitHub-Advisories + Echt-JAR-HEAD-Proben auf Maven Central erzeugt; wenn eine der sieben Assertions (Positivkontrolle / Kernaussage / Endversion der alten Linie / Sentinel / zentrale Struktur / gespaltene Module / Bewertung) nicht besteht, wird die Ausgabe der Tabelle verweigert.

Die drei Zustände der Verfügbarkeit von Fix-Versionen (der harte Kern dieses Tools)

Drei Zustände	Bedeutung
PUBLIC	Das Advisory benennt eine Fix-Version, und sie ist tatsächlich auf Maven Central vorhanden – öffentlich aktualisierbar
404	Das Advisory benennt eine Fix-Version, aber sie ist auf Central 404 – die offizielle Sicherheitsseite schreibt see details for availability (kommerzieller Support)
无	Das Advisory gibt für diese Linie überhaupt keine Fix-Version an (first_patched_version ist leer) – eine Behebung dieser Linie erfordert nur ein Upgrade über eine Hauptversion hinweg

Die ganze Fläche von 404 und 无 bei den alten Linien (9.4 / 10.0 / 11.0) ist genau der Wert dieses Tools. Führe --table aus, um das Gesamtbild zu sehen.

Die sechs abgedeckten Einträge (alle reviewed Advisories von org.eclipse.jetty, Jahr 2026)

CVE	Modul	Bewertung	Ein Satz
CVE-2026-2332	jetty-http	high / v3 7.4	⭐ Hauptdarsteller: \r\n in einem chunked quoted-string wird als Ende des Chunk-Headers behandelt → Request Smuggling (CWE-444)
CVE-2026-19203	jetty-http	high / v4 8.3	⭐ Fortsetzung derselben Familie wie 2332 (09-17): \n (LF) in einer Chunk-Erweiterung wird als Ende des Chunk-Headers behandelt → Smuggling (LF EXT.TERM); die 9.4-Linie ist bis 9.4.63 abgedeckt
CVE-2026-5795	jaspi (12.x aufgeteilt in ee8/9/10/11-jaspi)	high / v3 7.4	JASPI-ThreadLocal nicht bereinigt → Rechteausweitung
CVE-2026-6790	jetty-server	medium / v3 5.3	Host- / :authority-Verwechslung bei HTTP/2·3
CVE-2026-10050	jetty-security (12.x ergänzt um ee8/9-security)	high / v4 8.7	ISO-8859-1-Behandlung bei Digest-Authentifizierung
CVE-2025-11143	jetty-http	low / v3 3.7	Unterschiede bei der URI-Analyse

🔴 Die betroffene Fläche der beiden Schmuggel-Lücken (2332 und 19203) ist belastbar (beide liegen auf dem Standard-Parsing-Hauptpfad ServerConnector / HttpParser, ohne dass irgendeine bestimmte Funktion aktiviert werden muss). Die übrigen vier dienen nur als eine Zeile in der Entscheidungstabelle:

• ⚠️ Die 12.1-Linie von 19203 ist eine Ausnahme: 12.1.x im standardmäßigen RFC9110-Konformitätsmodus ist nicht betroffen, nur bei expliziter Konfiguration von RFC7230 / RFC2616 greift sie – dieses Tool kennzeichnet für 12.1.x diese Voraussetzung (sowohl in --table als auch in der Scan-Ausgabe), um Fehlalarme bei Standard-Deployments zu vermeiden. Die Linien 9.4 / 10 / 11 / 12.0 sind dagegen standardmäßig betroffen.
• Die betroffene Fläche von CVE-2026-10050 (Digest) ist sehr klein – sie ist nur bei explizit aktivierter Digest-Authentifizierung erreichbar, nicht als Hauptverkaufsargument verwenden.
• CVE-2026-6790 ist medium, CVE-2025-11143 ist low – nicht pauschal als „hochriskant“ bezeichnen.

Die Grenzen der Aussage (dieses Tool überschreitet sie nicht, du auch nicht)

• „Treffer im betroffenen Bereich“ ist eine Artefakt-Tatsache; „du wirst angegriffen“ ist etwas anderes. Die Formulierungen dieses Tools sind stets erstere.
• Die beiden zentralen Einträge (CVE-2026-2332 / CVE-2026-19203) sind beide Request-Schmuggel: Es muss davor noch ein Frontend-Proxy / LB vorhanden sein, und beide Enden müssen denselben Request unterschiedlich interpretieren, erst dann lässt sich von einer Gefahr sprechen. Bei einem nackt laufenden Jetty lässt sich keine Angriffsgeschichte erzählen – diese beiden haben CVSS v3 7.4 / v4 8.3, nicht „wer es installiert, ist erledigt“.
• „Die globale Schwachstellendatenbank liefert keinen Bereich“ ist eine Messung (Stand des Tages der Veröffentlichung): Das globale Advisory vulnerabilities von 19203 ist leer, Dependabot meldet „diese Lücke existiert“, kann aber nicht angeben „worauf man aktualisieren soll“; der Bereich steht nur im repository-level Advisory. Sobald die globale Datenbank nachzieht, muss dieser Satz geändert werden.
• „404 auf Central“ ist eine gemessene Tatsache; „der Hersteller versteckt den Patch, um Geld zu verdienen“ ist etwas, das du nicht für den Hersteller sagen solltest. Die offizielle Seite selbst schreibt see details for availability, und dabei bleibt es.
• Es bedeutet auch nicht „Jetty veröffentlicht keine Versionen mehr“ – die Linien 12.0 / 12.1 werden weiterhin aktualisiert, und die öffentlichen Fix-Versionen dieser beiden Linien sind auf Central vorhanden.

Primärquellen

• Haupt-Advisory:https://github.com/advisories/GHSA-355h-qmc2-wpwf(2332, enthält lauffähigen PoC und Links zur Funky-Chunks-Forschung)
• 19203 (Nachfolger derselben Familie wie 2332, LF EXT.TERM): Repository-Ebene https://github.com/jetty/jetty.project/security/advisories/GHSA-xc35-c22g-239h (Intervall und PoC befinden sich hier; die vulnerabilities des globalen GHSA-p2j5-5566-vpv9 sind leer)
• Vier weitere:GHSA-r7p8-xq5m-436c · GHSA-7p3p-8qv8-m2vh · GHSA-2fvj-hgj9-j2gr · GHSA-wjpw-4j6x-6rwh
• Offizielle Sicherheitsseite (Quelle für see details for availability):https://jetty.org/security.html
• Versionslinien-EOL:https://jetty.org/download.html

Vor der Neuerstellung / Veröffentlichung erneut prüfen

python tools/gen_table.py --dry              # 只跑断言,不写文件
python tools/gen_table.py                    # 断言全过才写 CveTable.java
python tools/recheck_before_publish.py       # 发文当天重跑,主张失效就改文案别改判据

Build