xiaoqimikko/tomcat85-check
CVE-2025-55752 CVE-2025-55754 CVE-2025-48988 CVE-2025-52520 CVE-2025-53506 CVE-2025-61795 CVE-2025-66614:Tomcat 8.5 EOL हो चुका है, अंतिम संस्करण 8.5.100। Apache ने एक-एक करके घोषणा की है कि "8.5 भी प्रभावित है" — 2025 के 14 CVE हैं, जिनमें से 10 NVD में 8.5.100 के अनुसार नहीं मिलते। ऑफ़लाइन सिंगल jar, conf/ पढ़कर पता लगाएँ कि आप वास्तव में किन-किन से प्रभावित हैं।
क्या आप अब भी Tomcat 8.5 चला रहे हैं?यह टूल आपको बताता है कि 2025 के कौन से CVE आप पर लागू होते हैं — क्योंकि इस सवाल का पूरा जवाब आपको आधिकारिक पेज, NVD, या स्कैनर से नहीं मिलेगा।
शून्य-निर्भरता वाला एकल jar, ऑफ़लाइन चलता है, नेटवर्क से नहीं जुड़ता, कुछ भी अपलोड नहीं करता।
Tomcat 8.5 2024-03-31 को EOL हो गया, अंतिम संस्करण 8.5.100 है (2024-03-19 को जारी)। उसके बाद भी Apache CVE रिकॉर्ड में एक-एक करके घोषित करता रहा कि "8.5 भी प्रभावित है", और यह बात सबसे कम लोग देखते हैं।
Apache आधिकारिक 9.x सुरक्षा पेज पर सूचीबद्ध CVE-2025-* कुल 17 हैं, जिनमें से 14 में शब्दशः लिखा है:
The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.x though 8.5.100
(मूल पाठ ऐसा ही है — 14 में से 8 में
throughकी जगहthoughलिखा है; निचली सीमा अधिकतर8.5.0है, कुछ में8.5.6/8.5.44/ / )
8.5.608.5.90ये 14 प्रविष्टियाँ, तीन जगहों पर आपको अलग-अलग रूप में दिखती हैं:
| आप जहाँ देखेंगे | आपको क्या दिखेगा |
|---|---|
Apache आधिकारिक 8.5 सुरक्षा पेज (security-8.html) | 2025 में शून्य प्रविष्टियाँ — पेज 2024-02-19 Fixed in Apache Tomcat 8.5.99 पर रुका हुआ है |
| NVD | 8.5.100 को cpe से खोजने पर इन 14 में से केवल 4 प्रविष्टियाँ मिलती हैं; बाकी 10 की cpe कॉन्फ़िगरेशन में 8.5 है ही नहीं |
| GitHub advisory | सभी 14 मौजूद हैं, लेकिन 8.5 वाली तरफ first_patched_version सभी में null है |
यह बात पूरी तरह से केवल CVE.org पर Apache द्वारा CNA के रूप में प्रस्तुत मूल रिकॉर्ड में लिखी है — यानी वह परत जिसे सबसे कम लोग खंगालते हैं। यह टूल बस उस परत की जानकारी को आपकी मशीन पर वास्तव में इंस्टॉल किए गए संस्करण के सामने रखता है।
🔴 यह टूल डेटा स्रोतों के बीच के अंतर को बताता है, किसी उत्पाद के व्यवहार को नहीं। "आपका स्कैनर इन 10 प्रविष्टियों को रिपोर्ट करेगा या नहीं" यह इस बात पर निर्भर करता है कि वह कौन सा डेटाबेस पढ़ता है और कैसे मर्ज करता है — इसका परीक्षण नहीं किया गया है, इसलिए यहाँ नहीं लिखा जाएगा।
सिर्फ़ वर्ज़न नंबर के आधार पर रिपोर्ट करने का मतलब है कि 12 ऐसी प्रविष्टियाँ जो "विशेष कॉन्फ़िगरेशन की माँग करती हैं" उन्हें भी "आप प्रभावित हैं" कहना — यानी आपको एक अनावश्यक काम करने के लिए कहना।
इसलिए जब इंस्टॉलेशन डायरेक्ट्री दी जाती है, तो यह टूल conf/ के अंतर्गत सभी XML पढ़ता है (जिसमें conf/Catalina/<host>/ भी शामिल है),
कमेंट ब्लॉक हटाकर फिर ट्रिगर कंडीशन के मार्कर खोजता है। कमेंट हटाना कोई विकल्प नहीं है:
आधिकारिक server.xml में UpgradeProtocol टेक्स्ट खोज 1 बार मिलता है, कमेंट हटाने के बाद 0 बार — वह पूरा हिस्सा कमेंट किया हुआ है।
आधिकारिक 8.5.100 बेयर इंस्टॉल पर आउटपुट ऐसा है:
डिफ़ॉल्ट रूप से प्रभावित 2 प्रविष्टियाँ · कॉन्फ़िगरेशन पुष्ट 0 प्रविष्टियाँ · मैन्युअल पुष्टि आवश्यक 11 प्रविष्टियाँ · लागू नहीं 1 प्रविष्टि
इनमें से 10 प्रविष्टियाँ NVD की cpe कॉन्फ़िगरेशन में 8.5 के रूप में नहीं मिलतीं
उसी कॉन्फ़िगरेशन में HTTP/2, RewriteValve, CGIServlet चालू करने के बाद, "कॉन्फ़िगरेशन पुष्ट" 5 प्रविष्टियाँ हो जाती हैं।
java -jar tomcat85-check.jar <इंस्टॉलेशन डायरेक्ट्री | jar | war> ...
--all "वर्ज़न रेंज में नहीं" वाली प्रविष्टियाँ भी सूचीबद्ध करें
--utf8 Windows कंसोल पर चीनी अक्षर गड़बड़ दिखें तो यह जोड़ें
# अनज़िप की गई तैनाती वाला Tomcat — conf/ वाली डायरेक्ट्री दें, मैन्युअल काम काफी कम हो जाएगा
java -jar tomcat85-check.jar /opt/tomcat
# सिर्फ़ एक jar / war से भी स्कैन हो सकता है
java -jar tomcat85-check.jar /opt/app/lib/catalina.jar
lib/ के अंतर्गत jar के फ़ाइल नाम में कोई वर्ज़न नंबर नहीं होता (यह catalina.jar है, catalina-8.5.100.jar नहीं)।
सिर्फ़ फ़ाइल नाम से वर्ज़न निकालने वाले टूल ऐसी तैनाती पर एक भी प्रविष्टि नहीं पहचान पाते —
और "कुछ स्कैन नहीं हुआ" बिल्कुल "आप सुरक्षित हैं" जैसा दिखता है।
यह टूल इस क्रम में वर्ज़न निकालता है:
catalina.jar!/org/apache/catalina/util/ServerInfo.properties का server.number
— Tomcat का अपना version.sh यही रिपोर्ट करता हैMETA-INF/MANIFEST.MF का Implementation-Versionजब दोनों स्रोत मेल नहीं खाते (ServerInfo.properties को ओवरराइड किया जा सकता है, अक्सर वर्ज़न छिपाने के लिए),
दोनों रिपोर्ट किए जाते हैं, आपके लिए चुनाव नहीं किया जाता।
एक: चालू होने की पुष्टि हो सकती है, बंद होने की नहीं।
रिपोर्ट में "नहीं मिला" का मतलब है मेरे द्वारा देखी गई फ़ाइलों में नहीं मिला, "आपने चालू नहीं किया" नहीं।
कॉन्फ़िगरेशन उन जगहों पर हो सकती है जहाँ यह टूल नहीं देख सकता: war के अंदर WEB-INF/web.xml, बाहरी CATALINA_BASE, स्टार्टअप पैरामीटर।
इसलिए "प्रभावित नहीं" जैसी कोई श्रेणी नहीं है — न मिलने पर हमेशा मैन्युअल पुष्टि आवश्यक में जाता है।
दो: मिल जाने का मतलब भी हमेशा वही नहीं होता।
जैसे आधिकारिक डिफ़ॉल्ट server.xml में AprLifecycleListener पहले से ही चालू है,
और यह सिर्फ़ native लाइब्रेरी लोड करने की कोशिश करता है — लाइब्रेरी मौजूद न होने पर APR कनेक्टर चालू नहीं होता।
इसलिए यह "कमज़ोर मार्कर" है: मिलने पर सिर्फ़ "संभव है" रिपोर्ट होता है, "पुष्ट" नहीं।
तीन: कोई अपग्रेड करने योग्य 8.5 वर्ज़न नहीं है।
14 प्रविष्टियों का first_patched_version 8.5 वाली तरफ सभी में null है।
यह "अभी ठीक नहीं हुआ" नहीं है, "8.5 के लिए अब ठीक नहीं होगा" है। एकमात्र रास्ता लाइन बदलना है (9.0 / 10.1 / 11.0)।
यह टूल "आप किससे प्रभावित हैं" का जवाब देता है, यह दिखावा नहीं करता कि "किस 8.5 पर अपग्रेड करें" का जवाब दे सकता है।
CVE-2025-55754 का उदाहरण लें, चारों नंबर सच हैं:
| किसने दिया | मान |
|---|---|
| Apache (ASF चार-स्तरीय) | low |
| GitHub advisory | low |
| CVSS v3.1 (NVD यही मानता है) | 9.6 critical |
| CVSS v4.0 | 2.1 |
अगर आप सिर्फ़ NVD देखें, तो लगेगा यह सबसे गंभीर प्रविष्टि है; सिर्फ़ Apache देखें, तो लगेगा इसे अनदेखा किया जा सकता है। दोनों गलत नहीं हैं — Apache डिफ़ॉल्ट कॉन्फ़िगरेशन में वास्तविक शोषण-क्षमता का मूल्यांकन करता है, CVSS वेक्टर के आधार पर यांत्रिक रूप से गणना करता है, यह नहीं देखता कि आपने वह फ़ीचर चालू किया है या नहीं।
इसलिए यह टूल चारों नंबर छापता है, और जब दोनों पक्ष अलग-अलग निर्णय देते हैं तो स्पष्ट रूप से बताता है।
Apache low / moderate / important / critical उपयोग करता है, GitHub low / medium / high / critical उपयोग करता है।
संरेखण का आधार Tomcat आधिकारिक security-impact.html के मूल पाठ से आता है:
Important / High — A vulnerability rated as Important (or High) impact is one which could result in the compromise of data or availability of the server.
→ Important और High एक ही स्तर के दो नाम हैं, यह आधिकारिक रूप से एक साथ लिखा गया है।
🔴 जबकि moderate और medium को आधिकारिक रूप से संरेखित नहीं कहा गया है, और यह टूल भी उन्हें संरेखित नहीं करता —
ASF का Moderate "महत्वपूर्ण शमन कारक / सामान्य कॉन्फ़िगरेशन को प्रभावित नहीं करता / प्रमाणीकरण आवश्यक" जैसी शोषण-क्षमता शर्तों को परिभाषित करता है,
GitHub का medium CVSS स्कोर रेंज है, दोनों एक चीज़ नहीं हैं। ऐसे मामले में "आधिकारिक रूप से इन दोनों स्तरों को बराबर नहीं कहा गया" रिपोर्ट होता है, दोनों आपके सामने रखे जाते हैं।
इस मानदंड के अनुसार, 14 में से 5 प्रविष्टियों में दोनों पक्षों का निर्णय वास्तव में अलग है (सबसे बड़ा अंतर CVE-2025-52520: Apache low / GitHub high),
2 संरेखित नहीं होतीं, 7 समान हैं।
निर्णय तालिका CveTable.java जनरेट की जाती है, एक भी पंक्ति हाथ से नहीं लिखी जाती:
python -u tools/fetch_sources.py # तीन प्राथमिक स्रोत लाएँ → tools/sources.json
python -u tools/gen_table.py # CveTable.java जनरेट करें (5 assertions, कोई भी विफल हो तो फ़ाइल नहीं लिखी जाती)
| स्रोत | किस सवाल का जवाब देता है |
|---|---|
| CVE.org (Apache द्वारा CNA के रूप में मूल रिकॉर्ड) | Apache ने खुद घोषित किया है कि "8.5 प्रभावित है" या नहीं, रेंज क्या है |
| NVD | cpe कॉन्फ़िगरेशन में 8.5 प्रविष्टि है या नहीं |
| GitHub advisory | severity, प्रभावित Maven निर्देशांक, 8.5 वाली तरफ फिक्स वर्ज़न है या नहीं |
प्रकाशन/रिलीज़ से पहले एक स्वतंत्र मानदंड वाली दोबारा जाँच भी चलाई जाती है — यह ऊपर वाली sources.json नहीं पढ़ती,
बल्कि जनरेट की गई CveTable.java को पार्स करती है, फिर cpe से NVD में एक बार खोजती है:
python -u tools/recheck_before_publish.py
यह चरण औपचारिकता नहीं है: इसने पहली बार चलने पर एक सच्ची गलती पकड़ी थी। जनरेट स्क्रिप्ट "NVD में 8.5 है या नहीं" का निर्णय करते समय सिर्फ़ "रेंज की निचली सीमा
8.5से शुरू होती है" मानती थी, जबकिCVE-2025-24813में लिखा हैversionStartIncluding=None .. versionEndExcluding=9.0.99— निचली सीमा खुली है, यह 8.5 को कवर करती है। अंतर सेट में इसलिए एक अतिरिक्त प्रविष्टि जुड़ गई थी। हरcveIdको अलग-अलग खोजने से यह कभी नहीं मिलती; "8.5.100 को cpe से एक बार खोजें" जैसे उपयोगकर्ता-दृष्टिकोण वाले मानदंड से ही यह सामने आया।
mvn package # → target/tomcat85-check.jar
mvn test # 59 टेस्ट
JDK 17+ चाहिए। रनटाइम पर शून्य निर्भरता, JUnit केवल टेस्टिंग के लिए।
MIT — देखें LICENSE