shiro-check

اكتشف وحدات Apache Shiro وإصداراتها المثبّتة فعليًا لديك، وحدّد بندًا بندًا أيًا من ثغرات CVE الرسمية الـ26 تنطبق فعليًا عليك.

ملف jar واحد بلا أي اعتماديات، دون اتصال بالشبكة، ودون قراءة ملف pom الخاص بك — بل يفحص مخرجات البناء مباشرةً (jar / war / fat jar / دليل).

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

---

لماذا لا يكفي «إلقاء نظرة على رقم الإصدار والانتهاء»

إن ثغرات CVE الخاصة بـ Shiro ليست معلّقة على «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 ثغرة تُفكَّك إلى 37 قاعدة تغطي 7 وحدات.

ثلاثة أمور لا تُرى عند المطابقة بالإحداثيات

1. خمس ثغرات لا تصل إلى تنبيهات Dependabot

يطابق Dependabot إرشادات GitHub الأمنية (advisory) حسب إحداثيات التبعية. من بين 26 بندًا، هناك 5 بنود لا تتطابق:

البند	سبب عدم التطابق
CVE-2026-56091 (تجاوز المصادقة في shiro-guice، خطورة عالية)	لا يزال الإرشاد الأمني بحالة unreviewed، والحزمة المتأثرة فارغة
CVE-2026-56130 (ملف تعريف ارتباط RememberMe لا ينتهي صلاحيته أبدًا)	كما هو الحال أعلاه
CVE-2014-0074 (تجاوز المصادقة بكلمة مرور LDAP فارغة)	كما هو الحال أعلاه
CVE-2023-22602 (تجاوز المصادقة في Spring Boot 2.6+، خطورة عالية)	الإرشاد الأمني مرتبط فقط بـ org.apache.shiro:shiro-root
CVE-2010-3863	كما هو الحال أعلاه

بينما shiro-root هو POM أب بـ packaging=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 واحد، أبلغت هذه الأداة عن 20 سجلًا عبر 3 وحدات.

3. هناك 3 سجلات لا يمكن الحصول على نسختها الرسمية المُصلحة من Maven Central

قيمة first_patched_version في 3 تنبيهات هي 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 الحقيقي (لا يُقبل «أتذكر أن هذا البند يخص الويب»)
• القابلية للتنفيذ: يُستعلم عن كل إصدار إصلاح في Maven Central مرة واحدة، وتُوسم الإصدارات غير المتاحة
• الادعاءات: عدد النقاط العمياء في Dependabot، والفروقات بين الوحدات، والوحدات المضمّنة في uber jar — يجب أن تظل جميعها صحيحة

قبل النشر يوجد أيضًا tools/recheck_before_publish.py، يعيد التحقق من الحجج الحاملة باستخدام مجموعة معايير مستقلة ثانية (لا يستورد سكربت الإنشاء، ولا يقرأ مخرجاته — فإعادة استخدام نفس منطق التحليل ستُعيد إنتاج الأخطاء نفسها).

القيود

• يغطي فقط 26 بندًا على صفحة security-reports الرسمية، ولا يشمل المشكلات غير المعلنة أو مشكلات التكامل مع أطراف ثالثة
• نوطاقات الإصدارات مأخوذة من المصادر الرسمية وGitHub، وعند اختلاف نادر بين المعيارين يُعتمد النطاق المهيكل على إحداثيات الوحدة
• لا يحلّل الإعدادات، لذا تتطلب البنود الشرطية أن تحكم بنفسك على تحقق الشرط
• جدول التحديد هو لقطة وقت الإنشاء؛ وقد يحوّل GitHub في أي وقت unreviewed إلى reviewed

---

English

shiro-check يفحص مخرجات البناء لديك (jar / war / fat jar / دليل) لتحديد وحدات Apache Shiro التي تُشحنها فعليًا، ثم يقيّم جميع 26 ثغرة CVE رسمية مقابل تركيبة الوحدة + الإصدار الدقيقة لديك.

سبب وجوده: ثغرات Shiro CVE مرتبطة بـالوحدات، لا بـ"Shiro". 13 من أصل 26 لا تمس shiro-core إطلاقًا. تعمل الأداة على مستوى CVE × الوحدة (37 قاعدة، 7 وحدات).

ثلاثة أمور لا تستطيع المطابقة القائمة على الإحداثيات رؤيتها:

1. 5 إدخالات لا تصل أبدًا إلى تنبيهات Dependabot — 3 استشارات لا تزال unreviewed مع قائمة حزم متأثرة فارغة؛ و2 مرتبطتان فقط بـorg.apache.shiro:shiro-root، وهو POM أبوي بـpackaging=pom بلا jar على Maven Central (HTTP 404)، لذا لا يعتمد أي مشروع عليه أبدًا.
2. shiro-all هو uber jar — يحتوي shiro-all-1.3.2.jar على 6 إدخالات pom.properties (core، web، spring، ehcache، quartz + نفسه). يُظهر pom الخاص بك إحداثيًا واحدًا؛ بينما يحمل الـjar كودًا بقيمة ثلاث وحدات.
3. 3 استشارات تشير إلى 3.0.0-alpha-2 كإصلاح، وهو إصدار لم يُنشر قط على Maven Central. تُعلِّم الأداة على هذه وتقترح إصدارًا يمكنك الترقية إليه فعليًا.