tomcat-check

실제 설치된 Tomcat 버전을 찾아내고, 2026년의 각 CVE에 대해 등급 두 세트와 트리거 조건을 동시에 제공합니다.

의존성 없는 단일 jar, 오프라인 실행, 네트워크 연결 없음, 어떤 것도 업로드하지 않음.

무엇을 해결하나

첫째, Spring Boot 프로젝트의 내장 Tomcat 버전은 pom에 없다.

spring-boot-starter-parent의 tomcat.version 속성이 관리하며, pom에서는 spring-boot-starter-web만 볼 수 있다. 그래서 이 도구는 **빌드 산출물(jar / fat jar / 설치 디렉터리)**을 스캔하며 pom을 읽지 않는다.

둘째, 일부 항목은 Dependabot 경고에 들어오지 않는다.

2026년 Tomcat은 29개의 CVE를 공개했으며, 그중 일부는 두 가지 메커니즘 때문에 Spring Boot 프로젝트 경고에 나타나지 않는다:

실제 효과: 내장 Tomcat 9.0.118을 사용하는 Spring Boot 애플리케이션의 Dependabot 패널이 모두 초록색인데, 이 도구는 4건의 적중을 보고하며, 그중 하나는 기본 구성에서 바로 노출된다.

셋째, 두 등급 체계의 기준이 다른데, 당신은 그중 하나만 볼 수 있다.

29건 중 17건이 두 등급 체계에서 2단계 이상 차이나며, 가장 극단적인 CVE-2026-41293은 공식 Low, GitHub critical CVSS 9.8이다.

이는 누가 잘못 보고한 것이 아니다. 두 체계는 원래 서로 다른 것을 측정한다. 하지만 「지금 업그레이드해야 하는지」를 판단하려면, 두 체계를 동시에 봐야 한다 —— 그리고 해당 기능을 켰는지도.

사용법

java -jar tomcat-check.jar <jar 或目录> ...

  --all     连「不适用」的条目也列出来
  --utf8    Windows 控制台中文乱码时加这个

# Spring Boot fat jar
java -jar tomcat-check.jar target/my-app.jar

# 独立安装的 Tomcat
java -jar tomcat-check.jar /opt/tomcat

# 整个依赖目录
java -jar tomcat-check.jar target/lib

Java 17+ 필요.

출력에는 무엇이 있는가

각 적중 항목은 두 등급 체계, 트리거 조건, 공식 설명 원문, 그리고 이 항목이 Dependabot 경고에 나타날지 여부를 제공한다. 마지막으로 모든 적중 항목을 포함할 수 있는 업그레이드 목표를 제시한다.

🔴 출력은 이렇게 읽으세요

• 「적중」= 당신의 버전이 공식 Affects 범위 안에 들어간다는 뜻이며, 「이미 이용됨」도, 「반드시 이용 가능함」도 아니다. 29건 중 소수만 기본 구성에서 바로 노출되며, 나머지는 특정 기능(RewriteValve, DIGEST 인증, AJP, WebDAV, 클러스터 통신……)을 명시적으로 켜야 한다. 각 항목을 트리거 조건과 대조하세요.
• 「Dependabot이 경고하지 않음」이 GitHub의 실책이라는 뜻은 아니다. unreviewed는 정상 프로세스 상태이다.
• 판정표는 2026년에 공개된 CVE만 다룬다. 적중이 없다고 해서 당신의 버전에 문제가 없다는 뜻은 아니다.
• 이 도구는 업그레이드 여부를 결정해 주지 않는다 — 결정에 필요한 세 가지를 제공한다: 어떤 버전을 설치했는지, 공식 평가가 무엇인지, 트리거 조건이 무엇인지.

판정표는 어떻게 만들어졌나

tools/gen_rules.py는 두 개의 1차 소스에서 CveTable.java를 생성하며, 한 줄도 직접 작성하지 않는다:

• https://tomcat.apache.org/security-{9,10,11}.html —— 공식 등급, 제목, 설명 원문, 영향 범위
• GitHub Advisory API —— GitHub 등급, CVSS, type, 영향받는 Maven 좌표

생성 과정에는 **7개의 단언(assertion)**이 있으며, 하나라도 충족되지 않으면 중단하고 파일을 쓰지 않는다. 그중 세 가지는 따로 설명할 가치가 있다:

• ASSERT7(파싱 완전성): 두 번째 독립적인 정규식 기준으로 항목을 다시 세어, 양쪽 집합이 완전히 동일해야 한다. 유래는 매우 은밀한 유형의 불일치다 — 공식 페이지의 일부 제목에는 다른 CVE의 링크가 포함되어 있다: <strong>Moderate: The fix for <a>CVE-2025-66614</a> was incomplete</strong> <a>CVE-2026-32990</a>. 전체 블록에서 「첫 번째 CVE」를 찾으면 제목에 포함된 그 이전 번호를 가져오게 되며, 결과는 한 건이 빠지는 것이 아니라 엉뚱한 짝짓기이다: 한 CVE가 다른 CVE의 제목과 설명에 붙게 되는데, 생성, 테스트, 실제 아티팩트 검증이 모두 정상적으로 통과한다.
• ASSERT3(짝짓기 방향): 공식 페이지의 Affects: 줄은 다음 CVE의 제목 바로 옆에 있어, 잘못된 항목과 짝지어지기 매우 쉽다 — 틀리면 「완전히 정상으로 보이지만 전체가 한 칸 어긋난」 표가 된다. GitHub의 first_patched_version으로 교차 검증했으며, 개발 중에 실제로 이 덕분에 한 번 어긋남을 잡아냈다.
• ASSERT6(제외 근거): 9.0 / 10.1 / 11.0 세 라인의 실제 jar를 다운로드하여, 제외된 항목(클러스터 컴포넌트, FFM 커넥터, 예제 애플리케이션)의 코드가 실제로 tomcat-embed-*에 없는지 하나씩 확인한다. 제외 근거는 실측이어야 하며, 「내 기억으로는」일 수 없다.

다시 생성:

python tools/gen_rules.py

빌드

mvn clean package     # → target/tomcat-check.jar

테스트 34개. 런타임 의존성 없음, JUnit은 테스트 전용.

라이선스

MIT