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 दो प्राथमिक स्रोतों से CveTable.java उत्पन्न करता है, एक भी पंक्ति हाथ से नहीं लिखी जाती:

• https://tomcat.apache.org/security-{9,10,11}.html —— आधिकारिक रेटिंग, शीर्षक, मूल विवरण, प्रभावित सीमा
• GitHub Advisory API —— GitHub रेटिंग, CVSS, type, प्रभावित Maven निर्देशांक

उत्पादन प्रक्रिया में 7 assertions हैं, यदि कोई भी पूरी न हो तो प्रक्रिया रुक जाती है और फ़ाइल नहीं लिखी जाती। इनमें से तीन पर विशेष रूप से चर्चा करने योग्य हैं:

• ASSERT7 (पार्सिंग पूर्णता): एक दूसरे स्वतंत्र regex मापदंड से प्रविष्टियों की फिर से गिनती करें, दोनों समुच्चय बिल्कुल समान होने चाहिए। इसकी उत्पत्ति एक बहुत ही सूक्ष्म गलत मिलान से हुई है — आधिकारिक पृष्ठ पर कुछ शीर्षकों में किसी अन्य 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