تأكيد SAML واحد بيفتح جلستين: حدّث Snipe-IT للإصدار 8.5.0 أو أحدث
على Snipe-IT لحد 8.4.1، تأكيد SAML ملتقط واحد بيفتح جلستين للضحية، وإبطال الجلسة من مزوّد الهوية بيوصل لوحدة منهن بس. الإصلاح بالإصدار 8.5.0.
إذا بتدير أصول الشركة على Snipe-IT وموظفينك بيدخلوا عليه بدخول SAML الموحّد، نشرة الأمان تبع المشروع على GitHub بتوصف ثغرة بتكسر أبسط افتراض بهالدخول: إنو التأكيد الواحد بينستعمل مرة وحدة. وإذا عندك هالإعداد، رح تعرف تحت إذا نسختك متأثرة، وكيف انكسرت الحماية، وكيف بتسكّر جلسة ممكن تكون ضلّت مفتوحة بعد ما مزوّد الهوية أبطلها.
قديش هالثغرة خطيرة؟
تقييمها عالي (High) على CVSS 4.0، مع إنو نشرة المشروع نفسه مصنّفتها «Moderate»؛ والإصلاح جاهز من أيار.
رقم الثغرة CVE-2026-116201 انتشر بتاريخ 25 تشرين الأول 2026، وتقييمها 8.7 على CVSS 4.0، حسب صفحة الثغرة عند VulnCheck. ونشرة المشروع على GitHub مصنّفتها «Moderate»، فلا تخلّي هالكلمة تأخّر التحديث: الثغرة بتعطي المهاجم جلسة دخول بحساب الضحية.
نشرة المشروع بتقول إنو الإصلاح بالإصدار 8.5.0. هالإصدار نزل بأيار، وملاحظاته بتقول إنو بيصلّح كذا مشكلة أمنية وبتنصح الكل يحدّث بأقرب وقت بيقدروا. النشرة نفسها طلعت بعده، 8 تشرين الأول 2026، ورقم CVE إجا بعدها. يعني يلي لسا على 8.4.1 أو أقدم، يلي النشرة بتقول إنها متأثرة، عنده إصلاح جاهز من أيار وما ركّبه.
كيف تأكيد واحد بيفتح جلستين؟
لأنو منع التكرار كان «افحص، سجّل دخول، وبعدين ضيف» بلا قفل، وقاعدة البيانات نفسها ما كانت بترفض نفس القيمة مرتين.
معالج SAML عند Snipe-IT بيمنع إعادة استعمال التأكيد بجدول saml_nonces: بيفحص إذا قيمة nonce تبع التأكيد موجودة، وإذا مش موجودة بيسجّل الدخول، وبعدين بيضيفها للجدول. هالحماية انكسرت من جهتين. أول شي، عمود nonce كان عليه فهرس عادي مش UNIQUE، فالجدول بيقبل نفس القيمة مرتين. وتاني شي، الفحص كان قبل Auth::login() والإضافة بعده، بلا معاملة (transaction) بتجمعهن، فما في شي بيمنع طلبين يمرقوا سوا.
فطلبين POST /saml/acs بنفس اللحظة وبنفس التأكيد الملتقط بيمرقوا الفحص سوا، وبيسجّلوا دخول سوا، وبيضيفوا القيمة مرتين. من تأكيد واحد بتطلع جلستين متوازيتين للضحية.
هالنوع من الغلط إله اسم معروف، «وقت الفحص ووقت الاستعمال» (TOCTOU)، والنشرة نفسها مصنّفة الثغرة تحته (CWE-367). والسباق هون نجح لسببين سوا: تسجيل الدخول كان قاعد بين الفحص والإضافة بلا معاملة، وعمود nonce ما كان عليه قيد UNIQUE يرفض القيمة التانية.
شو لازم يكون بإيد المهاجم؟
تلات شروط، وولا واحد منهن كلمة سر الضحية.
أول شي، دخول SAML مفعّل ومضبوط ببيانات IdP صحيحة. تاني شي، المهاجم معه تأكيد SAML صحيح واحد للضحية: من اعتراض الاتصال بين مزوّد الهوية والتطبيق (MITM)، أو من إضافة متصفح خبيثة، أو من تأكيد تسرّب بسجلات أو بترويسة Referer. تالت شي، بيبعت التأكيد مرتين جوّا نافذة السباق، وهي أقل من ثانية تحت حمل حقيقي.
ليش إبطال الجلسة من مزوّد الهوية ما بيكفي؟
لأنو الإبطال بيوصل لجلسة وحدة بس، والتانية بتضل فاتحة.
لما مزوّد الهوية بيبطل جلسة الضحية بعد ما تنكشف السرقة، الجلسة التانية يلي طلعت من نفس التأكيد بتضل شغّالة. الضحية وفريق الأمن بيفكروا إنو الإبطال سكّر القصة، والمهاجم لسا جوّا بجلسة ما وصلها الإبطال. هاد أخطر شي بهالثغرة، لأنو بيعطي إحساس إنو الباب تسكّر وهو لسا مفتوح.
ونفس الدرس شفناه مع مفاتيح UpdraftCentral المسروقة: الشي المسروق بيضل شغّال لحد ما تبطله إنت بإيدك.
شو غيّر الإصلاح بالإصدار 8.5.0؟
قلب الترتيب: صار يضيف القيمة أول ويلتقط التكرار حوالين Auth::login()، وصار عمود nonce عليه فهرس UNIQUE.
طلب الدمج يلي جاب الإصلاح بيقول إنو الكود صار يضيف سجل لجدول saml_nonces أول، وإذا قاعدة البيانات رفضته (غالباً لأنو مكرّر) الطلب بيفشل، وانزاد قيد UNIQUE على العمود. وحسب نشرة المشروع، القيد بينضاف بترحيل بيشغّل أول شي saml:clear_expired_nonces لحتى ينضّف الصفوف القديمة، وبعدين بيطبّق القيد.
بهالترتيب، الإضافة صارت قبل تسجيل الدخول، فالطلب التاني بيوقع عندها لأنو قاعدة البيانات نفسها بترفض القيمة المكرّرة، وما بيوصل لتسجيل الدخول أصلاً. فحص بالكود ممكن طلب تاني يسبقه بجزء من الثانية، أما القيد بقاعدة البيانات فما في طلب بيسبقه.
شو تعمل هلق؟
حدّث أول شي، وبعدين سكّر كل الجلسات إذا بتشكّ إنو تأكيد انسرق.
حدّث لآخر إصدار، وهو وقت كتابة هالمقال Snipe-IT 8.8.3.
ركّب 8.5.0 أقل شي إذا ما بتقدر توصل لآخر إصدار اليوم، لأنو نشرة المشروع بتقول إنو هو الإصدار يلي فيه الإصلاح.
دوّر بسجلات خادم الويب على طلبين
POST /saml/acsأو أكتر بنفس الثانية: هاد شكل التأكيد يلي انبعت أكتر من مرة.افحص كمان إنو كوكي الجلسة نفسه محمي، بالخطوات يلي بمقال كيف تفحص كوكي الجلسة بموقعك.
سكّر كل الجلسات بعد التحديث إذا بتشكّ إنو تأكيد انسرق: أمر
php artisan snipeit:global-logoutبيطلّع كل المستخدمين حسب كود الأمر نفسه عند Snipe-IT، وكل واحد بيرجع بيسجّل دخول. إبطال واحد من مزوّد الهوية ما بيكفي، لأنو ما بيوصل للجلسة التانية.
إمتى آخر مرة فحصت إنو فهرس قاعدة بياناتك بيمنع التكرار؟
إذا ما بتتذكر، افحصه اليوم: أي جدول بيمنع التكرار بفحص بالكود وبعدين إضافة، بلا قيد UNIQUE، معرّض لنفس السباق يلي صار عند Snipe-IT.
إذا عندك Snipe-IT مع SAML، حدّث اليوم. وبعدين دوّر بكودك على الجداول يلي بتحمل قيم لمرة وحدة، متل رموز تفعيل الحساب أو روابط تغيير كلمة السر، وشوف إذا قاعدة البيانات نفسها بترفض القيمة المكرّرة بقيد UNIQUE.
إذا بدك حدا يفحص هالشي بمنصتك قبل ما يلاقيه غيرك، مُحَصَّن بيفحص منصتك وبيسلّمك خطة إصلاح واضحة.
أسئلة شائعة
أنا على أي نسخة متأثر؟
كل نسخة لحد 8.4.1 متأثرة، والإصلاح من 8.5.0 وطالع. وأحسن شي تحدّث لآخر إصدار، مش بس للإصدار 8.5.0.
هل الثغرة بتشتغل بلا SAML؟
لأ. لازم يكون دخول SAML مفعّل ومضبوط ببيانات IdP صحيحة، وبلاه المسار المتأثر مش شغّال عندك. بس حدّث كمان، لأنو ملاحظات إصدار 8.5.0 بتقول إنو بيصلّح كذا مشكلة أمنية.
هل المهاجم بدّه كلمة سر الضحية؟
لأ. شروط النشرة الرسمية ما فيها كلمة سر: المهاجم بدّه تأكيد SAML واحد صحيح للضحية، وبيبعته مرتين بنفس اللحظة لحتى ياخد جلستين.
ليش نشرة المشروع بتقول Moderate والتقييم 8.7؟
لأنو التصنيفين من جهتين مختلفتين: نشرة المشروع على GitHub صنّفت الثغرة Moderate، والرقم 8.7 هو تقييم VulnCheck على CVSS 4.0، وهو High. والخطوة وحدة: حدّث.
إذا حدّثت، الجلسات المسروقة القديمة بتسكّر؟
مش حسب النشرة الرسمية: هي ما بتقول إنو التحديث بيسكّر جلسات مفتوحة، والإصلاح بيمنع إعادة الاستعمال من بعده. إذا بتشكّ إنو تأكيد انسرق، شغّل بعد التحديث أمر php artisan snipeit:global-logout، يلي بيسكّر جلسات كل المستخدمين، وكل واحد بيرجع بيسجّل دخول.
