단일 jar, 런타임 의존성 없음, 완전 오프라인, Java 17+.

왜 이런 도구가 필요한가

1. Netty는 하나의 버전 번호를 사용하지만, 각 모듈은 저마다의 "수정 버전"을 가집니다

모든 Netty 모듈은 동일한 버전 번호로 릴리스되므로 업그레이드가 단일 결정처럼 보입니다. 하지만 실제로는 그렇지 않습니다. 4.1 라인에서 이 14개 CVE의 수정 버전은 125 / 129 / 132 / 133 / 135 / 136 / 137 — 총 7개의 서로 다른 값에 걸쳐 있습니다. 어떤 권고문 하나만 따라가면 여전히 다른 CVE의 영향 범위 안에 남게 됩니다.

2. HTTP/2 CVE를 수정했다면, 여기서는 여전히 노출되어 있을 가능성이 높습니다

netty-codec-http2는 netty-codec-http를 <version>${project.version}</version>으로 지정한 compile 의존성으로 선언합니다 — 두 버전은 서로 고정되어 있습니다.

따라서 7개 netty-codec-http2 CVE를 해결하는 버전이기 때문에 4.1.136.Final로 업그레이드했다면, 이제 netty-codec-http도 4.1.136.Final로 실행되는 셈이며 — CVE-2026-59903은 <= 4.1.136.Final을 포함합니다. **4.1.137.Final**이 필요합니다. 4.2 라인도 마찬가지입니다: HTTP/2의 답은 4.2.16.Final이지만, 이쪽은 4.2.17.Final이 필요합니다.

이는 HTTP/2 권고가 틀렸다는 주장이 아닙니다 — 그것은 다른 모듈에 대한 답이었을 뿐입니다. "하나의 버전 번호"가 단 하나의 모듈에 대해서만 답하고 있었다는 사실을 숨긴다는 것이 이 도구의 주장입니다.

3. 경계 조건이 일관되게 표기되지 않았으며, 하나의 버전이 그 경계에서 결과가 뒤집힙니다

이 14개 권고문에서 상한 경계는 <=로 16회, <로 12회 표기되었습니다. 따라서 동일한 4.1.136.Final은 CVE-2026-56746(< 4.1.136.Final)에는 안전하지만 CVE-2026-59903(<= 4.1.136.Final)에는 영향을 받는 것으로 판정됩니다.

연산자를 어느 쪽으로든 정규화하면 잘못된 결과가 나옵니다 — 한 방향은 과다 보고, 다른 방향은 과소 보고를 하게 되며, 과소 보고는 이런 도구에게는 비용이 큰 실수입니다. 규칙 테이블은 각 연산자를 권고문이 작성한 그대로 유지하며, tools/gen_rules.py의 assertion은 이 경계 케이스가 더 이상 그렇게 동작하지 않게 되면 빌드를 실패시킵니다.

그리고 의도적으로 pom.xml을 스캔하지 않습니다

Spring WebFlux를 사용한다면 netty-codec-http는 다음 경로를 통해 유입됩니다

artifactId는 pom.xml에 나타나지 않습니다. pom 기반 점검은 "사용하지 않는다"고 답하지만, 그것은 틀린 답입니다. 이 도구는 실제로 배송되는 jar를 읽습니다.

사용법

종료 코드: 0 = 영향 없음 · 1 = 영향 있음 · 2 = 판정 불가.

🔴 2는 의도적으로 0이 아닙니다. "아무것도 찾지 못함"과 "안전함"은 스크립트 입장에서 같아 보여서는 안 됩니다. 읽을 수 없는 zip이 아닌 파일은 읽기 실패로 보고되며, 절대 "netty 없음"으로 조용히 처리되지 않습니다.

이 도구가 알려주지 않는 것

• 이 14개 CVE만, 그리고 netty-codec-http만 대상으로 합니다. 다른 Netty 모듈에는 자체 CVE가 있습니다; 여기서 깨끗한 결과가 나왔다고 해서 그것들에 대해 아무것도 말해주지 않습니다. netty-codec-http2도 실행 중이라면, 도구가 이를 알리고 위의 교차 모듈 문제를 지적하지만, 해당 모듈에 대해서는 판정하지 않습니다.
• 심각도는 게시된 그대로 보고됩니다. 14개 중 2개는 CVSS 점수가 없고 1개는 low입니다; 무서운 총점으로 합산하지 않고 있는 그대로 출력됩니다.
• 이 권고문들은 모두 전체 패키지 메타데이터와 함께 reviewed 상태입니다, 따라서 Dependabot 등이 실제로 경고를 발생시킵니다. 이 도구는 "스캐너가 볼 수 없다"는 것이 아니라 — "경고가 권고문별로 버전 번호를 알려주지만, 어떤 단일 버전이 그것을 끝내는지 여전히 직접 알아내야 한다"는 것입니다.

규칙 테이블이 만들어지는 방식

src/main/java/dev/mikko/nettyhttpcheck/RuleTable.java는 생성된 파일이며, 수동 편집하지 않습니다:

7개의 assertion이 통과해야만 아무것도 작성되지 않습니다 — 그중에는: 모든 권고문이 여전히 reviewed 상태인지; 각각에 대해 두 버전 라인이 모두 존재하는지; 계산된 교집합이 여전히 4.1.137.Final / 4.2.17.Final인지; 해당 버전이 실제로 Maven Central에서 가져올 수 있는지 (404가 나야 하는 센티널 버전으로, 손상된 프로브가 조용히 통과할 수 없도록 함); §3의 경계 케이스가 여전히 뒤집히는지; 그리고 §2의 HTTP/2 답이 여전히 이쪽에 구멍을 남기는지입니다.

실제 jar 엔드투엔드 검사는 tools/e2e_real_jars.py에 있습니다 — fixture가 아닌 Maven Central에서 실제 jar를 다운로드합니다. "손으로 만든 zip에서는 동작하지만 실제 jar에서는 실패한다"는 것이 실제 실패 모드이기 때문입니다.

라이선스

MIT