Skip to content
KitploitKITPLOIT
उपकरणएक्सप्लॉइटब्लॉग
Log in
जमा करें
उपकरणएक्सप्लॉइटब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

फ़ीडसंपर्कगोपनीयता© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
tomcat-check — 查出 Spring Boot 内嵌 Tomcat 的真实版本(pom 里没有),并对每条 2026 年 CVE 同时给出 ASF 官方评级与 GitHub 评级、触发条件、以及这条会不会进 Dependabot 告警 CVE-2026-41293 | Kitploit
उपकरण/GitHubGitHub/xiaoqimikko/tomcat-check
Vulnerability ScannersVulnerability AnalysisConfiguration AuditingWeb SecurityDevSecOpsSupply Chain Security
GitHubxiaoqimikko/tomcat-check

tomcat-check

查出 Spring Boot 内嵌 Tomcat 的真实版本(pom 里没有),并对每条 2026 年 CVE 同时给出 ASF 官方评级与 GitHub 评级、触发条件、以及这条会不会进 Dependabot 告警 CVE-2026-41293

रिपॉजिटरी देखें
112 दिन पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें
अनुरोधित भाषा में सामग्री उपलब्ध नहीं है। अंग्रेज़ी संस्करण दिखाया जा रहा है।

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-10-13,Tomcat 官方安全页上 2026 年的 CVE 有 51 条,其中 34 条因为下面两种机制不会出现在 Spring Boot 项目的告警里(unreviewed 29 条,坐标对不上 5 条):

机制说明
advisory 是 unreviewedGitHub 只用 reviewed 的 advisory 做 Dependabot 告警。unreviewed 是 NVD 自动导入、尚未人工确认受影响包的正常流程状态
坐标对不上advisory 挂在 org.apache.tomcat:tomcat-coyote 等坐标下,而 Spring Boot 的依赖树里只有 tomcat-embed-core / -el / -websocket

实际效果(2026-10-13 用 Central 上的真 jar 实跑):Spring Boot 3.5.16 自带的 tomcat-embed-core 10.1.55 + tomcat-embed-websocket 10.1.55,本工具报出 25 条命中, 其中 22 条进不了 Dependabot 告警;默认配置即暴露的是 1 条,其余都带前提,请逐条看触发条件。

这些数字会变:GitHub 随时可能把 unreviewed 的条目转成 reviewed。 重新生成判定表(见下文)就能拿到当天的状态。

三、两套评级体系口径不同,而你只看得到其中一套。

ASF / Tomcat 官方GitHub / NVD
分级Low / Moderate / Important / CriticalCVSS 数值
依据默认配置下的实际可利用性向量机械计算,不看你开没开那个功能
在哪看tomcat.apache.org/security-9.htmlDependabot 直接推送给你

51 条里有 23 条两套评级差 2 级以上(另有 9 条 GitHub 尚未给出评级,不计入),最极端的 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 区间内,不等于「已被利用」,也不等于「必然可利用」。 51 条里只有少数是默认配置即暴露,其余需要你显式开启某个功能(HTTP/2、WebSocket、RewriteValve、 DIGEST 认证、AJP、WebDAV、集群通信……)。请逐条对照触发条件。
  • WebSocket 类条目只在扫到 tomcat-embed-websocket 时才算命中。 内嵌形态下 WebSocket 实现 不在 tomcat-embed-core 里;你的应用如果把它排除掉了,这几条会列在「不适用」里并写明原因。
  • 「Dependabot 不会告警」不是说 GitHub 失职。 unreviewed 是正常流程状态。
  • 判定表只覆盖 2026 年公布的 CVE。 没有命中不等于你的版本没问题。
  • 工具不会替你决定要不要升级 —— 它给的是做这个决定所需的三样东西: 你装的是哪个版本、官方怎么评、以及触发条件是什么。

2026-08 与 2026-09 两批(v0.2.0 补进)

官方在 9.0.121 / 10.1.58 / 11.0.25 修了一批 10 条,在 9.0.122 / 10.1.60 / 11.0.26 又修了一批 12 条。 其中一条值得单说:

CVE-2026-86350(官方 Important)是修 CVE-2026-41293 时引入的回归。 它的受影响区间是 9.0.118–9.0.121、10.1.55–10.1.59、11.0.22–11.0.25 —— 也就是 41293 的修复版自己。 为了修 41293 升到这些版本的,需要再升一次。触发条件是启用了 HTTP/2。

这两批 22 条里,19 条在 GitHub 上仍是 unreviewed(2026-10-13 读数)。

判定表怎么来的

tools/gen_rules.py 从两个一手源生成 CveTable.java,一行都不手抄:

  • https://tomcat.apache.org/security-{9,10,11}.html —— 官方评级、标题、描述原文、影响区间
  • GitHub Advisory API —— GitHub 评级、CVSS、type、受影响 Maven 坐标

生成过程带 7 条断言,任一不满足就中止、不写文件。其中三条值得单说:

  • ASSERT7(解析完整性):用第二个独立的正则口径再数一遍条目,两边集合必须完全相同。 由来是一类很隐蔽的错配 —— 官方页面上有的标题里嵌着另一个 CVE 的链接: <strong>Moderate: The fix for <a>CVE-2025-66614</a> was incomplete</strong> <a>CVE-2026-32990</a>。 在整块里找「第一个 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

39 个测试。运行时零依赖,JUnit 仅测试期。

许可

MIT

需要更进一步的排查?

这个工具回答的是「我中没中」。下面这些它答不了,可以找我做:

  • 依赖被 shade / relocate 过,或者构建产物根本拿不到
  • 要判的是「这条 CVE 在我们的调用链上到底会不会触发」,而不只是版本命中
  • 要按你们自己的构建流程或内网环境做定制、接进现有流水线
  • 手上是另一个组件的同类问题,还没有现成工具

📮 [email protected] —— 说清情况,我 24 小时内给你一页书面答复: 能不能做、难在哪、大概多久。这一步免费,也不用你先承诺什么。

退出码

码含义
0扫完了,并且每个文件都真的读进去了,没有需要你动作的发现
4有文件读不动 —— 不是 zip、内容截断、或读取失败

🔴 4 是 2026-09-09 加的,加它的理由值得说清楚。 在此之前,读不动的文件只在输出里留一行提示,而退出码照旧是 0 —— 留痕是给人看的,CI 和脚本看的是退出码,于是「我没能读它」在自动化里等于「通过」。 一个损坏、加密或下载不全的 jar,会安静地变成一句「没发现问题」。

「我读不动它」和「你是安全的」必须是两句话。

⚠️ 合法的空 jar 不算读不动(一条 22 字节的 EOCD 记录是一个真的空 zip),不会触发 4 —— 假告警多了,真告警就没人看。

其余退出码的含义见上文各判定档位与用法说明。

टूल डाउनलोड करें