jetty-line-check

La tua installazione di Jetty (o il Jetty introdotto da Spring Boot), quali delle sei CVE del 2026 ha colpito — e la versione che l'ufficiale ti dice di aggiornare, esiste davvero su Maven Central?

Il focus principale è CVE-2026-2332 (GHSA-355h-qmc2-wpwf, high / CVSS v3 7.4): request smuggling chunked in jetty-http. Il 2026-09-17 l'ufficiale ha pubblicato anche la CVE-2026-19203 della stessa famiglia (smuggling LF EXT.TERM, high / CVSS v4 8.3): la sua linea 9.4 copre fino alla 9.4.63, l'ufficiale ti dice di aggiornare alla 9.4.64 — e la 9.4.64 su Central è anch'essa 404. Il fatto più solido: le versioni pubbliche con la correzione per le tre vecchie linee EOL 9.4 / 10 / 11 non esistono affatto — la pagina di sicurezza ufficiale per ciascuna di esse riporta see details for availability (= supporto commerciale), e quei numeri di versione su Maven Central risultano tutti 404 alla verifica pratica.

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 控制台中文乱码时加

Criterio: coordinate + linea di versione → tabella di verdetto + rilevamento del vero jar su Central

Il criterio del progetto gemello tomcat-line-check è «se nel jar c'è una certa classe di correzione», perché quella correzione di Tomcat ha aggiunto una nuova classe.

Per queste di Jetty non funziona. La principale, CVE-2026-2332, la cui correzione modifica il corpo del metodo di HttpParser, senza aggiungere alcuna classe (verificato prima della stesura con gh api compare + javap). Quindi il criterio può essere solo:

Le tue coordinate complete + linea di versione, quali CVE colpiscono; e se la versione corretta indicata ufficialmente esiste davvero su Maven Central.

La tabella di verdetto è generata da tools/gen_table.py a partire dai vulnerabilities[] di sei advisory GitHub + rilevamento HEAD del vero jar su Maven Central, e viene rifiutata se non passano sette gruppi di asserzioni (controllo positivo / tesi centrale / versione finale della vecchia linea / sentinella / struttura della principale / moduli separati / valutazione).

I tre stati della disponibilità della versione corretta (il cuore di questo strumento)

Tre stati	Significato
PUBLIC	l'advisory indica la versione corretta, ed essa è davvero su Maven Central —— aggiornabile pubblicamente
404	l'advisory indica la versione corretta, ma su Central è 404 —— la pagina di sicurezza ufficiale riporta see details for availability (supporto commerciale)
无	l'advisory non fornisce affatto la versione corretta per questa linea (first_patched_version è vuoto) —— per correggere questa linea bisogna passare a una major superiore

Tutta quella distesa di 404 e 无 delle vecchie linee (9.4 / 10.0 / 11.0) è proprio il valore di questo strumento. Esegui --table per vedere il quadro completo.

Le sei coperte (tutte advisory reviewed di org.eclipse.jetty, anno 2026)

CVE	Modulo	Valutazione	In una frase
CVE-2026-2332	jetty-http	high / v3 7.4	⭐ Principale: il \r\n all'interno di una quoted-string chunked viene interpretato come fine dell'header di chunk → request smuggling (CWE-444)
CVE-2026-19203	jetty-http	high / v4 8.3	⭐ Seguito della stessa famiglia di 2332 (09-17): il \n (LF) nelle estensioni di chunk viene interpretato come fine dell'header di chunk → smuggling (LF EXT.TERM); la linea 9.4 è coperta fino alla 9.4.63
CVE-2026-5795	jaspi (la 12.x si divide in ee8/9/10/11-jaspi)	high / v3 7.4	Il ThreadLocal di JASPI non viene ripulito → escalation di privilegi
CVE-2026-6790	jetty-server	medium / v3 5.3	Confusione tra Host / :authority in HTTP/2·3
CVE-2026-10050	jetty-security (la 12.x aggiunge ee8/9-security)	high / v4 8.7	Gestione ISO-8859-1 nell'autenticazione Digest
CVE-2025-11143	jetty-http	low / v3 3.7	Differenze nell'analisi degli URI

🔴 La superficie interessata delle due di request smuggling (2332 e 19203) regge (entrambe ricadono sul percorso principale di parsing predefinito ServerConnector / HttpParser, non serve abilitare alcuna funzione specifica). Le altre quattro valgono solo come una riga nella tabella di verdetto:

• ⚠️ La linea 12.1 di 19203 è un'eccezione: 12.1.x in modalità conforme RFC9110 predefinita non è interessata, solo con configurazione esplicita di RFC7230 / RFC2616 viene colpita —— questo strumento segnala questa premessa per 12.1.x (sia in --table sia nell'output della scansione), non generare falsi positivi sui deployment predefiniti. Le linee 9.4 / 10 / 11 / 12.0 invece sono colpite già in configurazione predefinita.
• La superficie interessata di CVE-2026-10050 (Digest) è molto piccola —— serve abilitare esplicitamente l'autenticazione Digest per entrarci in contatto, non usarla come argomento di vendita principale.
• CVE-2026-6790 è medium, CVE-2025-11143 è low —— non è consentito chiamarle tutte «ad alta gravità».

I confini del discorso (questo strumento non li supera, e nemmeno tu)

• «Colpisce l'intervallo interessato» è un fatto sull'artefatto; «sarai attaccato» è un'altra cosa. La formulazione di questo strumento è sempre la prima.
• Le due principali (CVE-2026-2332 / CVE-2026-19203) sono entrambe request smuggling: serve che davanti ci sia anche un proxy front-end / LB, e che le due estremità interpretino la stessa richiesta in modo incoerente, solo allora si può parlare di danno. Su un Jetty eseguito nudo non si può raccontare una storia di attacco —— queste due hanno CVSS rispettivamente v3 7.4 / v4 8.3, non è «chi lo installa è finito».
• «Il database globale delle vulnerabilità non riesce a ottenere l'intervallo» di 19203 è una misurazione reale (alla data di pubblicazione): il suo advisory globale ha vulnerabilities vuoto, Dependabot riesce a segnalare «c'è questa falla» ma non a dire «a cosa aggiornare»; l'intervallo esiste solo nell'advisory a livello di repository. Una volta che il database globale lo integrerà, questa frase va cambiata.
• «404 su Central» è un fatto misurato; «l'ufficiale nasconde la patch per venderla» è qualcosa che non devi dire al posto dell'ufficiale. La pagina ufficiale stessa scrive see details for availability, e ci si ferma qui.
• Non è nemmeno «Jetty non rilascia più versioni» —— le linee 12.0 / 12.1 sono ancora aggiornate, le versioni corrette pubbliche di quelle due linee sono entrambe su Central.

Fonti primarie

• Advisory principale: https://github.com/advisories/GHSA-355h-qmc2-wpwf (2332, include PoC eseguibile e link alla ricerca Funky Chunks)
• 19203 (seguito della stessa famiglia di 2332, LF EXT.TERM): advisory a livello di repository https://github.com/jetty/jetty.project/security/advisories/GHSA-xc35-c22g-239h (intervallo e PoC sono qui; il campo vulnerabilities del globale GHSA-p2j5-5566-vpv9 è vuoto)
• Altre quattro: GHSA-r7p8-xq5m-436c · GHSA-7p3p-8qv8-m2vh · GHSA-2fvj-hgj9-j2gr · GHSA-wjpw-4j6x-6rwh
• Pagina ufficiale di sicurezza (fonte di see details for availability): https://jetty.org/security.html
• Linee di versione EOL: https://jetty.org/download.html

Rigenerazione / verifica prima della pubblicazione

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

Compilazione

mvn package      # 需要 JDK 17;运行时零依赖(JUnit 仅测试期)

Codici di uscita