xiaoqimikko/jetty-line-checkCVE-2026-2332 및 2026년 Jetty CVE 4건 추가: 귀하의 Jetty(또는 Spring Boot) 빌드가 어떤 취약점에 해당하며, Jetty가 명시한 수정 버전이 Maven Central에 실제로 존재하기는 합니까? 9.4/10/11 EOL 라인의 경우 답은 '가용성은 세부 정보 참조' = 404입니다.
당신의 Jetty(또는 Spring Boot에 포함된 Jetty)가 2026년 이 여섯 개 CVE 중 몇 개에 해당하는가 — 그리고 공식에서 업그레이드하라고 하는 그 버전이 Maven Central에 실제로 존재하기는 하는가?
주력은 CVE-2026-2332(GHSA-355h-qmc2-wpwf, high / CVSS v3 7.4): jetty-http의 chunked 요청 밀수입니다.
2026-09-17 공식에서 같은 계열의 CVE-2026-19203(LF EXT.TERM 밀수, high / CVSS v4 8.3)을 또 발표했습니다: 이 CVE의 9.4 라인은 9.4.63까지 영향을 미치며,
공식에서는 9.4.64로 업그레이드하라고 하지만 — 9.4.64 역시 Central에서 404입니다.
가장 확실한 사실: 9.4 / 10 / 11 이 세 EOL 구 라인의 공개 수정 버전은 존재하지 않습니다 — 공식 보안 페이지에는 이들에 대해 하나하나
see details for availability(= 상용 지원)라고 적혀 있으며, 그 버전 번호들은 Maven Central에서 실측 결과 전부 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 控制台中文乱码时加
자매 프로젝트 tomcat-line-check의 판정 기준은 「jar 안에 특정 수정 클래스가 있는지」였습니다, Tomcat의 그 수정은 클래스를 하나 새로 추가했기 때문입니다.
Jetty의 이 항목들은 그렇게 할 수 없습니다. 주력인 CVE-2026-2332의 수정은 HttpParser의 메서드 본문을 바꾼 것이고, 새로 추가된 클래스는 없습니다
(작성 전에 gh api compare + javap으로 확인했습니다). 따라서 판정 기준은 다음뿐입니다:
당신의 전체 좌표 + 버전 라인이 어느 CVE에 해당하는지; 그리고 공식이 지목한 수정 버전이 Maven Central에 실제로 존재하는지.
판정표는 tools/gen_table.py가 여섯 개 GitHub advisory의 vulnerabilities[] + Maven Central 실제 jar HEAD 탐지로 생성하며,
일곱 가지 검증(양성 대조 / 핵심 주장 / 구 라인 최종판 / 센티널 / 주력 구조 / 분할 모듈 / 등급)을 통과하지 못하면 표 생성을 거부합니다.
| 삼태 | 의미 |
|---|---|
PUBLIC | advisory가 수정 버전을 지목했고 그것이 Maven Central에 실제로 존재함 —— 공개적으로 업그레이드 가능 |
404 | advisory가 수정 버전을 지목했지만 Central에서 404임 —— 공식 보안 페이지에 see details for availability(상용 지원)라고 적혀 있음 |
无 | advisory가 이 라인의 수정 버전을 아예 제시하지 않음(first_patched_version이 비어 있음) —— 이 라인을 고치려면 메이저 버전을 넘어 업그레이드해야 함 |
구 라인(9.4 / 10.0 / 11.0)의 그 404와 无 무더기가 바로 본 도구의 가치입니다. --table을 실행해 전체 양상을 보세요.
org.eclipse.jetty의 reviewed advisory, 2026년)| CVE | 모듈 | 등급 | 한 줄 요약 |
|---|---|---|---|
| CVE-2026-2332 | jetty-http | high / v3 7.4 | ⭐ 주력: chunked quoted-string 내의 \r\n이 청크 헤더 종료로 처리됨 → 요청 밀수(CWE-444) |
| CVE-2026-19203 | jetty-http | high / v4 8.3 | ⭐ 2332 동일 계열 후속(09-17): chunk 확장 내의 \n(LF)이 청크 헤더 종료로 처리됨 → 밀수(LF EXT.TERM); 9.4 라인은 9.4.63까지 적용 |
| CVE-2026-5795 | jaspi(12.x가 ee8/9/10/11-jaspi로 분리) | high / v3 7.4 | JASPI의 ThreadLocal 미정리 → 권한 상승 |
| CVE-2026-6790 | jetty-server | medium / v3 5.3 | HTTP/2·3의 Host / :authority 혼동 |
| CVE-2026-10050 | jetty-security(12.x에 ee8/9-security 추가) | high / v4 8.7 | Digest 인증 ISO-8859-1 처리 |
| CVE-2025-11143 | jetty-http | low / v3 3.7 | URI 파싱 차이 |
🔴 두 건의 밀수(2332와 19203)의 영향 범위는 타당합니다(둘 다 ServerConnector / HttpParser라는 기본 파싱 주 경로에 해당하며,
어떤 특정 기능도 켤 필요가 없습니다). 나머지 네 건은 판정표의 한 줄로만 취급합니다:
--table과 스캔 출력 모두에 있음), 기본 배포에 오탐하지 마세요. 9.4 / 10 / 11 / 12.0 라인은 기본적으로 해당됩니다.CVE-2026-10050(Digest)의 영향 범위는 매우 작습니다 —— Digest 인증을 명시적으로 활성화해야만 닿을 수 있으니 주력 판매 포인트로 삼지 마세요.CVE-2026-6790은 medium, CVE-2025-11143은 low입니다 —— 「고위험」으로 통칭해서는 안 됩니다.vulnerabilities가 비어 있어,
Dependabot은 「이 구멍이 있다」고 보고할 수 있지만 「어디로 올려야 하는지」는 제시하지 못합니다; 범위는 저장소 수준 advisory에만 있습니다. 전역 DB가 보완되면 이 문장은 수정해야 합니다.see details for availability이며, 거기까지입니다.GHSA-p2j5-5566-vpv9의 vulnerabilities는 비어 있음)GHSA-r7p8-xq5m-436c · GHSA-7p3p-8qv8-m2vh · GHSA-2fvj-hgj9-j2gr · GHSA-wjpw-4j6x-6rwhsee details for availability 출처): https://jetty.org/security.htmlpython tools/gen_table.py --dry # 只跑断言,不写文件
python tools/gen_table.py # 断言全过才写 CveTable.java
python tools/recheck_before_publish.py # 发文当天重跑,主张失效就改文案别改判据
mvn package # 需要 JDK 17;运行时零依赖(JUnit 仅测试期)
| 코드 | 의미 |
|---|---|
0 | 스캔 완료, 그리고 모든 파일을 실제로 읽어들임 |
2 | 사용법 오류(경로 미제공) |
4 | 읽을 수 없는 파일 존재 —— zip이 아니거나, 내용이 잘렸거나, 읽기 실패 |
🔴 4의 이유: 흔적 남기기는 사람이 보기 위한 것이고, CI와 스크립트가 보는 것은 종료 코드다. 이것이 없으면 손상되었거나 / 암호화되었거나 / 다운로드가 불완전한 jar가 조용히 "문제를 발견하지 못했습니다"라는 한마디로 변해버린다 —— "나는 그것을 읽을 수 없다"와 "당신은 안전하다"는 반드시 서로 다른 두 문장이어야 한다.
⚠️ 정상적인 빈 jar(22바이트짜리 EOCD 레코드 하나)는 읽을 수 없는 것으로 간주되지 않으며, 4를 트리거하지 않는다.
MIT