shiro-check

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

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

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

لماذا لا يكفي مجرد النظر إلى رقم الإصدار

CVE الخاصة بـ Shiro ليست معلّقة على «Shiro» نفسه، بل على وحدات محددة. الرقم نفسه يعني قواعد مختلفة باختلاف الوحدة:

من بين الإدخالات الرسمية الـ 26، 13 إدخالًا لا تمسّ shiro-core إطلاقًا. اختصارها في جملة واحدة مثل «Shiro < 1.7.1 به ثغرات» يعني اتخاذ القرار الذي كان ينبغي للمستخدم اتخاذه بنفسه — مع أن ذلك القرار خاطئ.

تعمل هذه الأداة بدقة CVE × الوحدة: تتوسع 26 CVE إلى 37 قاعدة تغطي 7 وحدات.

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

1. خمسة إدخالات لا تصل إلى تنبيهات Dependabot

يطابق Dependabot نصائح GitHub (advisories) وفق إحداثيات التبعية. خمسة من أصل 26 إدخالًا لا تتطابق:

أما shiro-root فهو POM رئيسي (parent POM) بنوع packaging=pom — لا يوجد jar مطابق له على Maven Central (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/<module>/pom.properties:

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

بعبارة أخرى، المشروع الذي يكتفي بكتابة shiro-all في ملف pom لديه اسم واحد فقط على مستوى الإحداثيات (من بين 26 إدخالًا، فقط CVE-2016-6802 معلّقة على هذا الإحداثي)، بينما يحوي الـ jar فعليًا كود ثلاث وحدات: core / web / spring.

فحص الأثر الفعلي يكشف هذه الطبقة. عند فحص shiro-all-1.3.2.jar فعلًا، تُبلغ الأداة عن 20 إدخالًا موزعة على 3 وحدات.

3. ثلاثة إدخالات لها إصدار إصلاح رسمي غير متاح على Maven Central

بالنسبة إلى ثلاثة advisories تكون قيمة 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 الافتراضي)،
                مع تكوين مسارات filter بأحرف صغيرة فقط في Shiro;يؤثر على الملفات الثابتة فقط

🔴 الأداة لا تحلل تهيئتك. يمكن ضبط 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 الجدول من مصدرين أوليين:

تتضمن عملية التوليد 12 تأكيدًا (assertions)؛ إذا لم يتحقق أي منها يتوقف التنفيذ دون كتابة الملف (لمنع «فشل التحليل فيولّد جدولًا أجوف بينما تبقى الاختبارات خضراء بالكامل»):

• الاكتمال: يجب أن يُحصي معيار عناوين h3 في المتن ومعيار مراسي الفهرس مجموعة CVEs نفسها
• تتبّع المصدر: نطاقات الإصدارات المعبأة يدويًا يجب أن تظهر سلسلة إصداراتها حرفيًا في النص الرسمي الأصلي
• الفحص الفعلي: يجب إثبات انتماء الوحدة عبر مواقع الفئات داخل jar حقيقي (لا يُقبل «أذكر أن هذا الإدخال يخص web»)
• قابلية التنفيذ: يُستكشف كل إصدار إصلاح على Maven Central مرة واحدة، وما لا يتوفر يُعلَّم عليه
• الادعاءات: عدد إدخالات مناطق العمى في Dependabot، والاختلافات بين الوحدات، والوحدات المضمّنة في uber jar — يجب أن تظل جميعها قائمة

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

القيود

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

الإنجليزية

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

لماذا وُجدت هذه الأداة؟ CVE الخاصة بـ Shiro تتعلق بـ الوحدات، لا بـ «Shiro». 13 من أصل 26 لا تمسّ shiro-core إطلاقًا. تعمل الأداة بدقة CVE × الوحدة (37 قاعدة، 7 وحدات).

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

1. 5 إدخالات لا تصل إلى تنبيهات Dependabot أبدًا — 3 advisories ما تزال بحالة 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 advisories تشير إلى 3.0.0-alpha-2 بوصفه الإصلاح، وهو إصدار لم يُنشر إلى Maven Central مطلقًا. تعلّم الأداة على هذه الحالات وتقترح إصدارًا يمكنك الترقية إليه فعلًا.

«الإصابة» تعني وحدة موجودة وإصدار ضمن النطاق الرسمي المتأثر. وهي لا تعني قابلية الاستغلال — معظم الإدخالات تتطلب تهيئة محددة تسردها الأداة حرفيًا من الـ advisory الرسمي. وهي لا تحلل تهيئتك عن قصد.

java -jar shiro-check.jar [--all] [--utf8] <jar | war | directory> ...

يتطلب JDK 17+. بلا تبعيات وقت تشغيل. يُولَّد جدول القواعد من مصدرين أوليين ويتضمن 12 تأكيدًا يتوقف التنفيذ عند فشلها؛ راجع tools/gen_rules.py.

الترخيص

Apache License 2.0