بين 14:05 و15:22 UTC أمس — وهي نافذة مدتها 77 دقيقة — نُشر عشرون CVE ضد PraisonAI، وهو إطار عمل متعدد الوكلاء. تمتد المعرّفات بشكل متتالٍ من CVE-2026-55522 إلى CVE-2026-55541. ويُنسب الفضل إلى ثلاثة عشر مُبلِّغًا منفصلًا. والأشد خطورة مُصنَّف بدرجة 9.1.
كلها تشير إلى التزام واحد
إن استخراج قائمة المراجع من جميع التنبيهات العشرين وإزالة التكرار عنها يعيد التزام إصلاح واحدًا فقط، حاضرًا في كل سجل من السجلات. وقد وُصف بوصفه تغييرًا لتعزيز التحقق من المدخلات، ودُمج في 13 يونيو 2026، وشُحن في ذلك اليوم. وبالتالي جاء الإفصاح بعد 73 يومًا من إصلاح الشيفرة. وقد قارنّا ملف الخادم المتأثر بين الإصدارين للتأكد من أن التغيير حقيقي وليس تجميليًا.
ما الذي يخطئ فيه التأطير الشائع
عشرون CVE لا تعني عشرين ثغرة. فقد جرى تفكيك التزام واحد لتعزيز الحماية، أنهى فئة من حالات فشل التحقق من المدخلات، إلى عشرين سجلًا منفصل الترقيم على يد ثلاثة عشر مُبلِّغًا يعملون على قاعدة الشيفرة نفسها. وأوضح مثال: ثلاثة من العشرين تصف الثغرة نفسها — وهي تجاهل وسيط مفتاح API — وتحمل درجات 8.6 و7.3 ومن دون أي درجة CVSS على الإطلاق. ثغرة واحدة، وثلاثة معرّفات، وثلاث معالجات مختلفة للخطورة. وفوق ذلك، فإن الوصف النصي في أحد التنبيهات لنطاق التأثير يتناقض مع نطاقه القابل للقراءة آليًا بفارق تسعة إصدارات.
لماذا يشوّه ذلك السجل
يُستخدم عدد CVE بوصفه مؤشرًا على مدى خطورة الاعتماد البرمجي — في الشراء، وفي أدوات الفحص، ولدى كل من يقارن الأطر. عشرون معرّفًا ضد مشروع واحد في فترة بعد الظهر تبدو كارثية، لكنها في الجوهر مجرد إصلاح واحد من يونيو. وفي الأثناء، فإن التكرار في التصنيف يجعل الفرز الآلي غير متماسك: سياسة ترفع التنبيه فوق 8.0 تنطلق على نسخة من الثغرة، وتتجاهل الثانية، ولا تستطيع رؤية الثالثة أصلًا.
الجزء السيئ حقًا
كل من لم يُحدّث منذ أوائل يونيو كان يشغّل شيفرة معروفة القابلية للاستغلال طوال شهرين ونصف من دون أي شيء في السجل العام ينبهه — لأن الإصلاح شُحن على هيئة التزام روتيني لتعزيز الحماية، وجاءت التنبيهات بعد 73 يومًا. تلك الفجوة، لا الرقم عشرين، هي التعرض الحقيقي.