ماذا حدث عندما أبلغت ميتا عن ثغرة في إشعارات فيسبوك

في أغسطس 2026، قدّمت بلاغاً لبرنامج مكافآت أخطاء ميتا (Bug Bounty) يصف سلسلة من المشاكل في ميزة "دعوة لإدارة بثك" (Invite to Manage Your Stream) الخاصة بفيسبوك - أداة دعوة مدير المجتمع (Community Manager Invite) خلال الأسابيع الستة التالية، مرّ البلاغ بجولتين من الرفض، وإعادة تقديم مع فيديو إثبات مفهوم، وإغلاق نهائي. هذا سجل لذلك التبادل، بالترتيب، مع ملاحظاتي الخاصة على كل مرحلة.

الاكتشاف

تتيح ميزة دعوة مدير المجتمع لمسؤول صفحة إرسال دعوة لأي مستخدم - بما في ذلك شخص ليس صديقاً له - يطلب منه المساعدة في إدارة بث مباشر. تُنشئ الدعوة إشعاراً مباشرة في لوحة الإشعارات الرئيسية للمستلم. هذا مهم لأن فيسبوك يعامل بالفعل الرسائل من غير الأصدقاء بشكل مختلف: على Messenger، تذهب رسالة غير مرغوبة من غريب إلى "طلبات الرسائل" (Message Requests)، وهو مجلد منفصل مبني تحديداً لتقليل التواصل غير المرغوب فيه. إشعار دعوة مدير المجتمع لا يمر عبر أي شيء مشابه لذلك. يهبط في نفس المكان الذي تهبط فيه الإشعارات من أشخاص تعرفهم فعلياً.

بالإضافة إلى ذلك، وجدت أن اسم عرض الصفحة يُدرَج مباشرة في نص الإشعار. بما أنه يمكن ضبط اسم الصفحة على أي سلسلة نصية تقريباً، يمكن لذلك الحقل أن يعمل كرسالة نصية حرة لغريب - على سبيل المثال، تسمية صفحة بـ"رسالة مخصصة بدل اسم الصفحة هنا" وظهور تلك السلسلة النصية بالضبط في إشعارات شخص ما.

ثلاثة سلوكيات إضافية فاقمت المشكلة:

• إذا حذف المسؤول الدعوة أو الصفحة بعد إرسالها، يبقى الإشعار ظاهراً للمستلم رغم ذلك. النقر عليه لا يؤدي لأي مكان، مما يؤكد أن سجل الدعوة الكامن قد اختفى من جانب الخادم - لكن الإشعار نفسه لم يُبطَل أبداً.
• إذا رفض المستلم الدعوة صراحة، يمكن للمسؤول إرسال واحدة أخرى فوراً. لا توجد فترة انتظار مرتبطة بالرفض. وجدت فعلاً حداً عاماً لمعدل الإرسال يوقف المسؤول بعد حوالي 20 طلباً، لكنه غير مرتبط بالمستلم المحدد أو بقراره بالرفض - إنه سقف إرسال عام، لا حماية لكل ضحية على حدة.
• عملية GraphQL mutation الكامنة خلف الدعوة (CometGamingVideoMutationsCommunityManagerBulkInviteMutation) أعادت خطأ خادم حرجاً (CRITICAL) من نوع field_exception في عدة مناسبات، مع الإبلاغ عن نتيجة الـmutation كـnull - ومع ذلك تم تسليم الدعوة والإشعار بغض النظر. العميل يرى فشلاً؛ المستلم يحصل على الإشعار على أي حال.

وثّقت كل واحدة من هذه بخطوات إعادة الإنتاج، والطلب والاستجابة الخام من تبويب الشبكة (network tab)، ومعرّفات التتبّع (trace IDs) لربط سجلات ميتا الداخلية.

الجدول الزمني

17 أغسطس 2026 - تقديم البلاغ

قدّمت البلاغ، بعنوان "Community Manager Invite: Notification Persists After Deletion, Bypasses Non-Friend Message Filtering, and Non-Atomic GraphQL Mutation Delivers Invite Despite Reported Server Error (PoC included)". خصّص الرد الآلي من ميتا رقم البلاغ 1815397989614160 وطلب مني الانتظار قبل الإفصاح العلني ريثما يراجعونه.

19 أغسطس 2026، 3:05 مساءً - الرفض الأول

بعد يومين، ردّت ميتا بما يبدو رداً نموذجياً جاهزاً:

"بعد مراجعة بلاغك، قررنا أن المشكلة المُبلَّغ عنها لا تُعتبر ثغرة صالحة ضمن نطاق برنامج مكافآت الأخطاء لدينا. قد يكون هذا لأن السلوك الموصوف يعمل كما هو مقصود، أو يقع خارج نطاق برنامجنا، أو لا يُظهر تأثيراً أمنياً أو خاصاً بالخصوصية واضحاً. نظراً لحجم البلاغات التي نتلقاها حالياً، لا يمكننا تقديم معلومات مفصلة حول كيفية توصلنا لهذا القرار."

لم يُقدَّم أي تبرير محدد - فقط قائمة بالفئات المحتملة التي قد يندرج تحتها الرفض، دون تحديد أيها ينطبق.

19 أغسطس 2026، 3:16 مساءً - ردّي

رددت في نفس اليوم، مُضيّقاً الحجة لما اعتبرته جوهر المشكلة: هذه ليست مجرد دعوة غير مرغوبة، إنها طريقة لتمرير نص حر متجاوزاً حماية بناها فيسبوك بالفعل للتواصل من غير الأصدقاء. عرضت سلوك استمرار الإشعار بعد الحذف وغياب فترة انتظار مرتبطة بالرفض كأدلة داعمة، وعرضت تقديم فيديو أو تكرار الاختبار على حسابات اختبار ميتا الخاصة.

25 سبتمبر 2026، 4:04 مساءً - الرفض الثاني

بعد أكثر من شهر، ردّت ميتا مجدداً، هذه المرة بهيكلية أوضح لكن بنفس النتيجة:

"فحصنا السلوك الذي وصفته مقابل السلوك المقصود للمنتج، ومقابل نطاق برنامجنا. لم نجد طريقة يمكن لشخص ما من خلالها استخدام هذا السلوك للتأثير على أمان/خصوصية بيانات مستخدمي ميتا. كما لم نجد طريقة لهم لاتخاذ إجراء غير مسموح لهم به بالفعل. رسالتك الأخيرة لم تضف تفاصيل تقنية تغيّر هذا الاستنتاج."

طلبوا أربعة أشياء محددة إذا أردت الاستئناف أكثر: تعليمات خطوة بخطوة قابلة لإعادة الإنتاج من حساب جديد، الطلب/النقطة النهائية (endpoint) والاستجابة بالضبط، أقصى تأثير قابل للتحقيق ضد ضحية، وفيديو أو لقطات شاشة.

26 سبتمبر 2026، 2:22 مساءً - تقديم فيديو إثبات المفهوم

رددت بشرح مُوقَّت زمنياً يغطي كل النقاط الست للسلسلة - إعداد الصفحة، إرسال الدعوة، حذف الصفحة، الإشعار لا يزال ظاهراً برابط ميت، الرفض متبوعاً بإعادة إرسال فورية، وتبويب شبكة أدوات المطوّر (DevTools) يُظهر الخطأ الحرج جنباً إلى جنب مع التسليم الناجح - بالإضافة لرابط لفيديو يوتيوب غير مُدرَج (unlisted).

29 سبتمبر 2026، 12:36 ظهراً - الإغلاق النهائي

بعد ثلاثة أيام، أُغلقت القضية:

"لقد حققنا في بلاغك وخلصنا إلى أنه بينما قد يكون السلوك الذي أبلغت عنه غير متوقع، إلا أنه لا يملك تأثيراً أمنياً/خاصاً بالخصوصية. بما أن ما تصفه لا يبدو ثغرة أمنية، نشجعك على الإبلاغ عن خطأ برمجي عام."

هذا الرد، الموقّع من شخص يُدعى "Sparrow" في فريق أمان ميتا، أقصر من الردّين السابقين ولا يشير للفيديو، أو أثر الشبكة، أو أي من النقاط المحددة التي طرحتها في رسالتي الأخيرة. إنه أول رد في المحادثة يعترف بأن السلوك "غير متوقع" بينما لا يزال يُغلقه كغير أمني.

السؤال المفتوح

بعد الرفض النهائي، تحققت من إحصائيات YouTube Studio لفيديو إثبات المفهوم غير المُدرَج الذي رابطته في ردّي بتاريخ 26 سبتمبر. يُظهر صفر مشاهدات - ليس تفاعلاً منخفضاً، صفر، عبر الفترة بأكملها منذ الرفع، وصفر في لوحة الوقت الفعلي أيضاً.

لا يمكنني التأكيد أن هذا يعني أن الفيديو لم يُشاهَد أبداً. عدّادات مشاهدة الفيديوهات غير المُدرَجة يمكن أن تفشل في التسجيل لأسباب لا علاقة لها بما إذا كان إنسان قد فتح الرابط - ماسحات الروابط المؤسسية وأدوات المعاينة المعزولة (sandboxed) أحياناً تُحمّل صفحة دون تنفيذ السكريبت الذي يحسب المشاهدة، ويمكن لحاجبات الإعلانات أو إضافات الخصوصية أن يكون لها نفس التأثير. لذا صفر مشاهدات ليس دليلاً على صفر مشاهدة فعلية. لكن ما هو عليه فعلاً، هو غياب أي دليل على أن الفيديو شُوهد، جنباً إلى جنب مع رفض لم يتعامل مع أي شيء خاص بمحتوى الفيديو. أعتقد أن هذا التزامن يستحق التسمية، حتى دون القدرة على استخلاص استنتاج قاطع منه.

أين يترك هذا الأمور

أنا لا أزعم أن فريق فرز بلاغات ميتا تجاهل البلاغ. من الممكن أن الفيديو رُوجع بطريقة لا تُسجّل مشاهدة، وأن التبرير كان سليماً، وأن السلوك يقع فعلياً خارج ما يعتبرونه مشكلة أمنية. لا أستطيع استبعاد ذلك، وأعتقد أنه من المهم قول ذلك بوضوح بدل المبالغة في عرض القضية.

ما يمكنني قوله هو أن العملية لا تمنح أي طريقة للتمييز بين مراجعة دقيقة تختلف مع تقييمي وفحص سريع لم يتعامل مع الأدلة المحددة المُقدَّمة. كلاهما ينتج نفس نوع الرد. بالنسبة لباحث يقرر ما إذا كان استمرار التوثيق، والاختبار، وإعادة التقديم لاكتشاف ما يستحق الوقت، فإن ذلك التمييز هو ما يهم فعلياً - وهو ما لا تُظهره العملية الحالية.