Skip to content
KitploitKITPLOIT
도구블로그
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
spring-cvss-check — Java 아티팩트와 소스를 스캔하여 Spring/Tomcat CVE를 탐지하고, 공급업체와 NVD의 CVSS 점수를 비교하며, 악용 가능성 조건을 검증하고, Maven Central에 수정 버전이 존재하는지 확인합니다. | Kitploit
도구/GitHubGitHub/xiaoqimikko/spring-cvss-check
Vulnerability ScannersVulnerability AnalysisConfiguration AuditingDevSecOpsSupply Chain Security
GitHubxiaoqimikko/spring-cvss-check

spring-cvss-check

Java 아티팩트와 소스를 스캔하여 Spring/Tomcat CVE를 탐지하고, 공급업체와 NVD의 CVSS 점수를 비교하며, 악용 가능성 조건을 검증하고, Maven Central에 수정 버전이 존재하는지 확인합니다.

저장소 보기
19시간 56분 전아직 검토되지 않음

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유

spring-cvss-check

Spring / Tomcat 공식 보안 권고 15건 커버(2026-08-20 7건 · 2026-06-08 5건 · 2025-09-15 1건 · Tomcat 2026-08-25 2건).

그중 8건은 NVD를 참조하는 스캐너가 CRITICAL 9.1~9.8로 보고하지만, 벤더 공식 평가는 LOW / MEDIUM이다. 나머지 7건은 양쪽 평가가 완전히 일치한다 — 차이는 단 하나: 벤더가 CVE 레코드에 CVSS 점수를 직접 제출했는지 여부.

이 도구는 네 가지 질문에 답한다:

  1. 내 버전이 이 15건 중 어떤 것에 해당하는가
  2. 공식 평가 점수는 얼마인가(그리고 NVD의 그 점수는 누가 매긴 것인가)
  3. 트리거 조건을 실제로 충족하는가(버전 번호만 비교하는 것이 아니라 소스와 설정을 스캔)
  4. 공식이 업그레이드하라고 한 버전이 Maven Central에 존재하는가

비교표

CVE컴포넌트벤더 공식NVDNVD 점수 제공자
CVE-2026-59313Spring FrameworkLOW9.8 CRITICALCISA-ADP
CVE-2026-47890Spring FrameworkLOW9.8 CRITICALCISA-ADP
CVE-2026-59283Spring FrameworkMEDIUM9.1 CRITICALCISA-ADP
CVE-2026-47891Spring FrameworkMEDIUM9.8 CRITICALCISA-ADP
CVE-2026-47884Spring FrameworkMEDIUM9.8 CRITICALCISA-ADP
CVE-2026-47892Spring FrameworkMEDIUM9.8 CRITICALCISA-ADP
CVE-2026-65637Apache TomcatModerate9.8 CRITICALCISA-ADP
CVE-2026-65905Apache TomcatLow9.8 CRITICALCISA-ADP
CVE-2026-59270Spring SecurityCRITICAL9.4 CRITICAL벤더 자체 평가 ✅ 일치

양쪽이 일치하는 유일한 항목은 바로 벤더가 NVD에 CVSS를 직접 제출한 항목이다.

원인은 누군가 정보를 숨겨서가 아니다: 벤더가 점수를 제출하지 않으면 CISA-ADP가 최악의 시나리오로 자동 채점하며, 대부분의 SCA 도구는 NVD의 값을 사용한다. 이것은 버그가 아니라 두 평가 체계의 각기 다른 기준이다 — 하지만 당신의 대응 프로세스는 9.8 기준으로 돌아간다.

두 번째 문제: 공식이 업그레이드하라고 한 버전을 다운로드하지 못할 수 있다

실측(양성 대조 포함, 규칙 테이블 생성 시마다 재실행):

root@kitploit:~
spring-web           6.2.19 = 200   ← 이전 버전은 Central에 있음
spring-web           6.2.20 = 404   ← 공식이 업그레이드하라고 한 버전, 없음
spring-security-core 6.5.11 = 200
spring-security-core 6.5.12 = 404

공식 Fix version 표에서 이 버전들은 Enterprise Support Only 로 표시된다 — 상용 지원을 구매한 고객에게만 제공. 따라서 실제로 해당된다면 선택지는:메이저 버전 업그레이드 또는 상용 지원 구매.

사용법

root@kitploit:~
java -jar spring-cvss-check.jar <jar|war|디렉터리>... [--src <소스 디렉터리>]
root@kitploit:~
# 가장 일반적: 빌드 산출물로 버전 확인, 소스로 트리거 조건 확인
java -jar spring-cvss-check.jar target/ --src src/main

# fat jar / war 하나만 있어도 됨
java -jar spring-cvss-check.jar app.war

JDK 17+ 필요. 런타임 의존성 없음, 네트워크 불필요.

종료 코드:0 버전 미해당 · 2 버전 해당하지만 트리거 조건 미발견 · 3 트리거 조건도 충족.

출력 예시

root@kitploit:~
== 스캔된 버전 ==
  Spring Framework   6.2.19         .../spring-core-6.2.19.jar
  Spring Security    6.5.11         .../spring-security-core-6.5.11.jar
  Apache Tomcat      9.0.37         .../tomcat-embed-core-9.0.37.jar

== 버전 해당 8건 ==

-- CVE-2026-47884  Spring Framework XsltView의 부적절한 경로 제한
   제품      Spring Framework  영향 범위 6.2.0 - 6.2.19
   [차이]    공식 **MEDIUM**   <->   NVD **CRITICAL 9.8**
             NVD의 그 점수는 벤더가 준 것이 아니라 CISA-ADP가 매긴 것.
   트리거 조건  XsltView를 사용하고, 뷰 렌더링을 거치는 "/**" 매핑이 존재하며, 뷰 이름이 명시적으로 지정되지 않은 경우에만
   [해당]    코드/설정에서 발견:
             src/main/java/demo/ReportView.java  <-  XsltView(2행)
   [업그레이드 불가]  공식은 6.2.20으로 업그레이드하라고 함 —— **Maven Central에 이 버전 없음(404)**, 공식 표기 Enterprise Support Only

== 요약 ==
  당신의 스캐너는 이 8건 중 7건을 CRITICAL로 보고할 수 있음;
  하지만 **벤더 공식** 평가는: 3건 LOW / 4건 MEDIUM / 1건 CRITICAL.
  이 8건 중 6건은 소스에서 트리거 조건을 찾지 못했고, 2건은 찾았음.
  [!] 이 중 7건은 공식이 제공한 수정 버전이 **Maven Central에 존재하지 않음**

반대편 — 나머지 7건이 왜 차이가 없는가

위 표만 보면 "NVD가 항상 점수를 잘못 매긴다"고 생각할 수 있다. 아니다. 같은 데이터 배치에 7건이 더 있는데, 공식 평가와 NVD 평가가 완전히 일치한다:

CVE컴포넌트벤더 공식NVDNVD 점수 제공자
CVE-2026-59270Spring SecurityCRITICAL9.4 CRITICAL벤더 자체 평가
CVE-2026-41843Spring FrameworkMEDIUM5.9 MEDIUM벤더 자체 평가
CVE-2026-41844Spring FrameworkMEDIUM4.2 MEDIUM벤더 자체 평가
CVE-2026-41846Spring FrameworkMEDIUM5.9 MEDIUM벤더 자체 평가
CVE-2026-41853Spring FrameworkMEDIUM5.3 MEDIUM벤더 자체 평가
CVE-2026-41848Spring FrameworkLOW3.7 LOW벤더 자체 평가
CVE-2025-41249Spring FrameworkHIGH7.5 HIGH벤더 자체 평가

두 방향 모두 반례가 없다, 이것이 이 도구가 유일하게 내릴 수 있는 인과 판단이다:

  • 7건 평가 일치 → 점수 출처가 전부 [email protected](벤더 직접 제출)
  • 8건 평가 불일치 → 점수 출처가 전부 CISA-ADP(벤더 미제출, 제3자가 최악의 시나리오로 자동 채점)

생성 스크립트는 두 개의 단언으로 각각의 방향을 감시한다(ASSERT4 / ASSERT7), 어느 하나라도 반례가 나오면 테이블 생성을 거부한다.

🔑 왜 두 방향을 검증해야 하는가: "일치하는 것은 모두 벤더 자체 평가다"라는 조건은 "일치하지 않는 것 중에도 벤더 자체 평가가 있을 수 있다"는 것을 배제하지 않는다. 실제로 그런 항목이 나오면 인과에 반례가 생기는데, 한 방향만 검증하면 전체 테이블이 그대로 생성되고 전부 초록불이 뜬다. 단방향 단언으로는 인과를 증명할 수 없다.


기준 — 결론을 내리기 전에 함께 읽어주세요

  • "미해당"이 "안전"을 의미하지는 않는다. 트리거 조건이 당신이 의존하는 서드파티 라이브러리에 있을 수도 있고, 환경 변수나 설정 센터를 통해 내려올 수도 있으며, 단지 소스 디렉터리를 전달하지 않았을 수도 있다. 보고서의 표현은 항상 "소스에서 찾지 못함"이지 "영향을 받지 않음"이 아니다.
  • 위에 나열된 네 배치, 총 15건만 커버하며, 전체 취약점 스캐너가 아니고 SCA를 대체하지 않는다.
  • 커버 범위에는 Spring Framework 5.3 라인(2024-08-31에 OSS 지원 종료, 최종 버전 5.3.39)이 포함된다. spring-core-5.3.39.jar로 실행하면 11건이 해당하는데, 이 11건에 대해 공식이 제공한 수정 버전은 공개 Maven Central에 하나도 존재하지 않는다(5.3.45 / 5.3.49 / 5.3.50, 전부 Enterprise Support Only 표기).
  • 텍스트 매칭만 수행하고 AST는 하지 않는다. 이는 의도적인 절충이다:핵심 경로는 사람이 읽고 직접 검증할 수 있어야 한다 — 이해할 수 없는 판정은 오류가 발생해도 아무도 발견하지 못한다.
  • 평가 차이는 객관적 수치일 뿐이며, "벤더가 숨기고 있다"도 "NVD가 잘못 보고한다"도 아니다.

데이터 출처 / 직접 검증 방법

판정 테이블은 tools/gen_rules.py가 4개의 1차 소스에서 생성하며, 수기 작성이 아니다:

소스가져오는 것
Aspring.io/security/<cve>공식 평가 / 영향 범위 / 수정 버전(OSS ⟷ Enterprise 표기 포함)
Btomcat.apache.org/security-{9,10,11}.html동일
CNVD REST APINVD 평가 및 점수 출처
Drepo1.maven.org(HEAD)공식이 업그레이드하라고 한 버전이 Central에 실제로 있는지

다시 실행하면 재검증이 된다:

root@kitploit:~
python tools/gen_rules.py

스크립트에는 6개의 단언이 있고, 통과하지 못하면 테이블 생성을 거부하며, 그중 3개는 이 도구의 주장을 직접 감시한다:

  • ASSERT2 공식⟷NVD 불일치 건수 —— 0이 되면 주장이 무효화된 것이므로 즉시 중단
  • ASSERT3 Central 탐지에 양성 대조 포함 —— 대조가 통과하지 못하면 해당 배치의 404는 전부 무효
  • ASSERT4 일치하는 항목의 점수 출처가 벤더 자체 평가여야 함 —— 이것이 "원인"의 유일한 증거

License

Apache-2.0

도구 다운로드