shiro-check

आपके द्वारा वास्तव में इंस्टॉल किए गए Apache Shiro मॉड्यूल और संस्करणों को स्कैन करें, और आधिकारिक 26 CVE में से प्रत्येक के लिए निर्धारित करें कि कौन से वास्तव में आप पर लागू होते हैं।

शून्य निर्भरता वाला एकल jar, इंटरनेट से कनेक्ट नहीं होता, आपकी pom नहीं पढ़ता —— सीधे बिल्ड आर्टिफैक्ट (jar / war / fat jar / निर्देशिका) को स्कैन करता है।

java -jar shiro-check.jar --utf8 your-app.jar

---

क्यों नहीं है «संस्करण संख्या देखकर काम खत्म कर देना»

Shiro के CVE «Shiro» पर नहीं, बल्कि विशिष्ट मॉड्यूल पर लटके हैं। एक ही संख्या अलग-अलग मॉड्यूल पर अलग-अलग नियम है:

CVE	प्रभावित मॉड्यूल	केवल shiro-core इस्तेमाल करने वाले
CVE-2020-17510	shiro-spring	प्रभावित नहीं
CVE-2020-17523	shiro-web / shiro-spring / shiro-spring-boot-starter	प्रभावित नहीं
CVE-2023-34478	shiro-web	प्रभावित नहीं
CVE-2026-56091	shiro-guice	प्रभावित नहीं

आधिकारिक 26 में से, 13 पूरी तरह से shiro-core को नहीं छूते। उन्हें एक वाक्य «Shiro < 1.7.1 में छेद है» में समेट देना, उपयोगकर्ता के लिए वह निर्णय लेना है जो उसे स्वयं लेना चाहिए था — और वह भी गलत तरीके से।

इस उपकरण का निर्धारण स्तर CVE × मॉड्यूल है: 26 CVE 37 नियमों में विस्तारित, 7 मॉड्यूल को कवर करते हुए।

तीन बातें जो निर्देशांक से मिलान करने पर नहीं दिखतीं

1. 5 Dependabot अलर्ट में नहीं आ सकते

Dependabot 按依赖坐标匹配 GitHub advisory。26 条里有 5 条对不上:

条目	为什么对不上
CVE-2026-56091(shiro-guice 认证绕过,high)	advisory 仍是 unreviewed,受影响包为空
CVE-2026-56130(RememberMe cookie 永不过期)	同上
CVE-2014-0074(LDAP 空口令绕过)	同上
CVE-2023-22602(Spring Boot 2.6+ 认证绕过,high)	advisory 只挂在 org.apache.shiro:shiro-root 上
CVE-2010-3863	同上

और shiro-root packaging=pom वाला पैरेंट POM है — Maven Central पर कोई संबंधित jar नहीं है (HTTP 404), कोई भी प्रोजेक्ट इस पर निर्भर नहीं करता, इसलिए निर्देशांक से मिलान कभी सफल नहीं होगा।

ℹ️ unreviewed GitHub की सामान्य प्रक्रिया स्थिति है (NVD स्वचालित आयात, प्रभावित पैकेज अभी मानवीय रूप से चिह्नित नहीं), निर्देशांक से मिलान भी एक उचित डिज़ाइन है। यहाँ केवल «अलर्ट में नहीं आ सकते» इस तथ्य को कहा गया है, यह नहीं कि किसी ने गलती की।

2. uber jar में अन्य मॉड्यूल छिपे हैं

shiro-all एक uber jar है जिसमें कई मॉड्यूल पैक किए गए हैं। वास्तविक परीक्षण में shiro-all-1.3.2.jar के अंदर 6 META-INF/maven/org.apache.shiro/<मॉड्यूल>/pom.properties हैं:

shiro-all  shiro-core  shiro-web  shiro-spring  shiro-ehcache  shiro-quartz

यानी, जिन परियोजनाओं के pom में केवल shiro-all लिखा है, निर्देशांक स्तर पर उनका बस एक ही नाम है (26 में से केवल CVE-2016-6802 इसी निर्देशांक पर है), जबकि jar में वास्तव में core / web / spring तीनों मॉड्यूल का कोड मौजूद रहता है।

वास्तविक वस्तु को स्कैन करने से यह परत उजागर हो जाती है। एक shiro-all-1.3.2.jar पर वास्तविक परीक्षण में, यह टूल 3 मॉड्यूल में फैली 20 प्रविष्टियाँ रिपोर्ट करता है।

3. 3 प्रविष्टियों के आधिकारिक फिक्स संस्करण Maven Central पर उपलब्ध नहीं हैं

3 advisory का first_patched_version 3.0.0-alpha-2 है, और यह संस्करण कभी Maven Central पर जारी नहीं हुआ (आधिकारिक रूप से सीधे 3.0.0 स्थिर संस्करण जारी किया गया)। उसके अनुसार अपग्रेड करना संभव नहीं है —— यह टूल इसे चिह्नित करेगा, और अपग्रेड सुझाव को वास्तव में उपलब्ध संस्करण से बदल देगा।

निर्धारण का अर्थ "आप प्रभावित हुए हैं" नहीं है

"हिट" = यह मॉड्यूल मौजूद है और संस्करण आधिकारिक प्रभावित सीमा में आता है। इसका अर्थ "पहले से शोषित" या "निश्चित रूप से शोषणीय" नहीं है।

26 में से अधिकांश के लिए विशिष्ट कॉन्फ़िगरेशन आवश्यक है, इसलिए टूल उन्हें अलग-अलग सूचीबद्ध करता है:

• 🔴 डिफ़ॉल्ट कॉन्फ़िगरेशन में ही प्रभावित —— प्राथमिकता से निपटें (जैसे CVE-2026-43827 session fixation)
• ⚠️ विशिष्ट शर्तें पूरी होना आवश्यक —— प्रत्येक के लिए शर्त दी गई है, पूरी न हो तो प्रभावित नहीं

शर्त का उदाहरण (आधिकारिक विवरण के मूल पाठ से शब्दशः मिलान, कोई अनुमान नहीं):

CVE-2026-49268  仅当使用 DefaultLdapRealm(用户名未转义即拼进 LDAP DN)
CVE-2023-22602  仅当与 Spring Boot 2.6+ 一起使用,且未把
                spring.mvc.pathmatch.matching-strategy 设回 ant_path_matcher
CVE-2026-23903  仅当静态文件放在大小写不敏感的文件系统上(如 macOS 默认设置),
                且 Shiro 里只配了小写的 filter 路径;只影响静态文件

🔴 टूल आपके कॉन्फ़िगरेशन को पार्स नहीं करता। Shiro को shiro.ini / application.yml / Java कोड में कॉन्फ़िगर किया जा सकता है, पार्स किए गए निष्कर्ष न पार्स करने से अधिक खतरनाक हैं। शर्तें स्पष्ट रूप से सूचीबद्ध हैं, निर्णय आप स्वयं करें —— यह जानबूझकर किया गया डिज़ाइन है, आलस्य नहीं।

उपयोग

# 扫一个 jar / war
java -jar shiro-check.jar your-app.jar

# 扫整个目录(递归)
java -jar shiro-check.jar /path/to/libs

# 连「不适用」的条目也列出来
java -jar shiro-check.jar --all your-app.jar

# Windows 控制台中文乱码时
java -jar shiro-check.jar --utf8 your-app.jar

पहचान क्षमता: सामान्य jar · Spring Boot fat jar (BOOT-INF/lib/) · पारंपरिक WAR (WEB-INF/lib/) · uber jar (shiro-all, अंदर के मॉड्यूल खोलकर) · नाम बदला गया jar (pom.properties को आधार मानकर) · बैकस्लैश से पथ लिखे गए विकृत आर्काइव।

JDK 17+ आवश्यक है। रनटाइम पर शून्य निर्भरता।

निर्णय तालिका कैसे बनी

एक पंक्ति भी हाथ से नहीं लिखी गई। tools/gen_rules.py दो प्राथमिक स्रोतों से उत्पन्न करता है:

स्रोत	क्या प्रदान करता है
shiro.apache.org/security-reports.html	प्रविष्टियों का पूर्ण सेट, विवरण का मूल पाठ, ट्रिगर शर्तों का मूल पाठ
GitHub Advisory API	प्रभावित मॉड्यूल निर्देशांक, संरचित संस्करण श्रेणियाँ, रेटिंग

उत्पादन प्रक्रिया में 12 एसेर्शन हैं, कोई भी पूरा न हो तो फ़ाइल लिखे बिना रोक दिया जाता है («पार्सिंग विफल होने पर खोखली तालिका बने और परीक्षण फिर भी हरे रहें» से बचाव):

• पूर्णता: मुख्य पाठ के h3 मानक और विषय-सूची एंकर मानक से समान CVE समूह गिना जाना चाहिए
• स्रोत-अनुसरण: मानव द्वारा भरे गए संस्करण अंतराल का संस्करण स्ट्रिंग आधिकारिक मूल पाठ में शब्दशः मौजूद होना चाहिए
• वास्तविक परीक्षण: मॉड्यूल आबंटन वास्तविक jar में क्लास की स्थिति से प्रमाणित होना चाहिए («मुझे याद है यह web का है» स्वीकार्य नहीं)
• निष्पादन-योग्य: प्रत्येक फ़िक्स संस्करण को Maven Central पर एक बार जाँचा जाता है, जो उपलब्ध न हो उसे चिह्नित किया जाता है
• दावे: Dependabot ब्लाइंड-स्पॉट की संख्या, क्रॉस-मॉड्यूल अंतर, uber jar में सम्मिलित मॉड्यूल — ये सभी अभी भी मान्य होने चाहिए

प्रकाशन से पहले tools/recheck_before_publish.py भी है, जो दूसरे स्वतंत्र मानक से भार-वहन करने वाले तर्कों को फिर से जाँचता है (जनरेटर स्क्रिप्ट को import नहीं करता, न ही उसका आउटपुट पढ़ता है — वही पार्सिंग लॉजिक दोबारा इस्तेमाल करने से बग भी साथ में दोहरा दिए जाते)।

सीमाएँ

• केवल आधिकारिक security-reports पृष्ठ की 26 प्रविष्टियाँ शामिल हैं, अप्रकाशित या तृतीय-पक्ष एकीकरण की समस्याएँ शामिल नहीं
• संस्करण अंतराल आधिकारिक स्रोत और GitHub से लिए गए हैं; दोनों के मानक में कभी-कभी अंतर होने पर मॉड्यूल निर्देशांक पर संरचित अंतराल को आधार माना जाता है
• कॉन्फ़िगरेशन का विश्लेषण नहीं किया जाता, इसलिए शर्त-आधारित प्रविष्टियों के लिए आपको स्वयं निर्धारित करना होगा कि शर्त पूरी होती है या नहीं
• निर्णय तालिका उत्पादन के समय का स्नैपशॉट है; GitHub कभी भी unreviewed को reviewed में बदल सकता है

---

English

shiro-check आपके बिल्ड आर्टिफ़ैक्ट्स (jar / war / fat jar / directory) को स्कैन करता है ताकि पता चले कि आप वास्तव में कौन से Apache Shiro मॉड्यूल शिप करते हैं, फिर आपके सटीक मॉड्यूल + संस्करण संयोजन के विरुद्ध सभी 26 आधिकारिक CVE का मूल्यांकन करता है।

यह क्यों मौजूद है: Shiro CVE मॉड्यूल से जुड़े होते हैं, "Shiro" से नहीं। 26 में से 13 तो shiro-core को बिल्कुल भी स्पर्श नहीं करते। यह टूल CVE × मॉड्यूल के स्तर पर काम करता है (37 नियम, 7 मॉड्यूल)।

तीन चीज़ें जो निर्देशांक-आधारित मिलान नहीं देख सकता: