اختراق Vercel عبر Context.ai: كيف كشفت أداة ذكاء اصطناعي واحدة منصة بأكملها

أداة ذكاء اصطناعي من طرف ثالث تصبح نقطة الدخول

في 18 أبريل 2026، أكدت Vercel — الشركة التي تقف خلف Next.js وواحدة من أكثر منصات استضافة الواجهة الأمامية استخداماً — حادثاً أمنياً بدأ خارج محيطها. وفقاً لإفصاح الشركة، استغل المهاجمون تطبيق OAuth خبيثاً أو مخترَقاً في Google Workspace، مرتبطاً بـ Context.ai، وهي أداة إنتاجية ذكاء اصطناعي من طرف ثالث يستخدمها موظف واحد فقط في Vercel. أعطى تفويض OAuth المهاجمين الوصول إلى حساب Google Workspace لذلك الموظف، ثم استخدموه للانتقال إلى بيئات Vercel الداخلية.

تبنّى الاختراق مهاجم يقدّم نفسه على أنه ShinyHunters على BreachForums، وهي المجموعة نفسها المسؤولة عن سلسلة OAuth في Salesloft/Drift في وقت سابق من 2026. عرضت ShinyHunters قاعدة بيانات Vercel الداخلية ومفاتيح الوصول وشيفرة المصدر وحسابات الموظفين ومفاتيح API ورموز NPM ورموز GitHub للبيع بمبلغ مليوني دولار، وشاركت 580 سجلاً للموظفين كدليل.

استعانت Vercel بـ Mandiant للتحقيق الجنائي، وأبلغت سلطات إنفاذ القانون، ونشرت إرشادات معالجة للعملاء تشمل التدوير الإلزامي لبيانات الاعتماد. صرّحت الشركة بأن Next.js وسلسلة التوريد الأوسع لـ Vercel لم تتأثر، وأن متغيرات البيئة المحددة صراحةً بوصفها “حساسة” لم تُظهر أي دليل على الوصول — فقط المتغيرات التي لم تُصنَّف تم كشفها.

ما الذي أخذه المهاجمون

يشمل النطاق المُعلن للاختراق، استناداً إلى نشرة Vercel والأدلة التي نشرتها ShinyHunters:

• 580 سجلاً للموظفين — أسماء، بريد إلكتروني، حالة الحساب، وطوابع زمنية
• متغيرات بيئة غير حساسة — مفاتيح API، رموز، بيانات اعتماد قواعد البيانات، ومفاتيح التوقيع غير المصنفة “حساسة”
• لوحات معلومات داخلية — أدوات تشغيلية يستخدمها موظفو Vercel
• شظايا من شيفرة المصدر — ليست مستودع Next.js مفتوح المصدر، بل شيفرة Vercel الداخلية
• رموز — بما في ذلك رموز NPM و GitHub المذكورة في قائمة الفدية

استبعاد المتغيرات “الحساسة” ليس مطمئناً ظاهرياً. التصنيف الحساس هو علامة يتحكم فيها المطور؛ أي مفتاح API أو بيانات اعتماد قاعدة بيانات أو مفتاح توقيع مخزّن بشكل صريح داخل متغير غير حساس أصبح الآن مُعرضاً للاختراق محتملاً. بالنسبة لعملاء Vercel، مسار المعالجة هو تدوير كل بيانات اعتماد مكشوفة عبر متغيرات البيئة بغض النظر عن العلامة الحساسة.

لماذا يُعدّ Context.ai هو القصة الحقيقية

نضج Vercel الهندسي مرتفع. تُشغّل الشركة منصة إنتاج مُحصّنة مع مصادقة متعددة العوامل ومفاتيح عتاد وسياسات وصول صارمة. لم يكن أيٌّ من ذلك مهماً هنا. لم تستهدف الهجمة البنية التحتية الإنتاجية لـ Vercel؛ استهدفت حساب Google Workspace لموظف واحد عبر تفويض OAuth لأداة ذكاء اصطناعي من طرف ثالث فعّلها الموظف لإنتاجيته الشخصية.

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

ليست Context.ai أداة مغمورة؛ بل هي واحدة من عشرات تكاملات إنتاجية الذكاء الاصطناعي التي يثبتها الموظفون لتلخيص الاجتماعات أو صياغة البريد الإلكتروني أو تحليل الوثائق. تطلب كل من هذه الأدوات عادةً نطاقات Google Workspace واسعة تشمل الوصول إلى Gmail و Drive و Calendar. اختراق واحد — سواء للبنية التحتية للأداة الذكية نفسها أو لتسجيل OAuth — يُحوّل كل موظف يستخدم تلك الأداة إلى ناقل وصول أولي محتمل.

سلسلة توريد SaaS لديها مشكلة حوكمة

وجد تقرير Unit 42 العالمي للاستجابة للحوادث 2026 أن 23% من الحوادث شملت مهاجمين يستغلون تطبيقات SaaS من طرف ثالث للتحرك الجانبي، صعوداً من نسبة مئوية أحادية الرقم قبل عامين. ووجد تقرير Bastion 2026 لأمن سلسلة التوريد أن 70% من المؤسسات عانت على الأقل من حادث أمني واحد مرتبط بطرف ثالث أو بسلسلة التوريد البرمجية في العام الماضي، وأن 15% فقط من مسؤولي أمن المعلومات (CISOs) لديهم رؤية كاملة لسلسلة التوريد.

يُجسّد اختراق Vercel هذه الفجوة. لم تختر Vercel Context.ai كمورّد. لم تكن هناك مراجعة مشتريات، ولا تقييم أمني، ولا اتفاقية معالجة بيانات. أضافها موظف إلى سير عمله، وأذن بنطاقات OAuth في مربع حوار بنقرة واحدة، وكان ذلك كافياً لإنشاء مسار ثقة من أنظمة Vercel إلى من يتحكم بتسجيل OAuth لـ Context.ai.

خمسة ضوابط كانت ستوقف هذه السلسلة

الضوابط التقنية لمنع اختراق الطرف الثالث القائم على OAuth راسخة جيداً، لكن اعتمادها لا يزال متفاوتاً:

1. القائمة البيضاء لتطبيقات OAuth — يدعم كل من Google Workspace و Microsoft 365 تقييد تطبيقات OAuth من الأطراف الثالثة التي يمكن للموظفين الإذن لها. تترك معظم المؤسسات هذا الإعداد مفتوحاً افتراضياً.
2. سياسات الموافقة القائمة على النطاقات — حظر أي تطبيق OAuth يطلب نطاقات كاملة للبريد أو Drive دون مراجعة أمنية صريحة.
3. المراجعة الدورية لتفويضات OAuth — تدقيق ربع سنوي للتطبيقات المأذون لها مع إلغاء تلقائي للتفويضات غير المستخدمة أو عالية الخطورة.
4. الوضع الافتراضي لتصنيف المتغير الحساس — عكس علامة “الحساس” بنمط Vercel بحيث تُعامَل جميع متغيرات البيئة كحساسة ما لم يتم تحديدها كعامة صراحةً.
5. اكتشاف الشذوذ في بيانات الهوية — مراقبة المواقع الجغرافية غير المعتادة وأنماط إصدار الرموز والنشاط API الضخم على حسابات الموظفين، والتي ستُنبّه إلى جلسات مُختطَفة قبل اكتمال استخراج البيانات.

لا شيء من هذه الضوابط جديد. ما يُظهره حادث Vercel هو أنه في عالم SaaS-first، لم تعد هذه الضوابط نظافة اختيارية — بل هي الدفاع الحامل ضد فئة اختراق تمثل الآن ما يقرب من ربع جميع الحوادث التي تحقق فيها Unit 42.

المصادر والقراءات الإضافية

• Vercel Data Breach Exposes 580 Employee Records via Third-Party AI Tool — Cyber Security News
• 2026 Unit 42 Global Incident Response Report — Palo Alto Networks
• 2026 Unit 42 Global Incident Response Report: Attacks Now 4x Faster — Strategic Focus
• 2026 Supply Chain Security Report — Bastion
• Vercel April 2026 Incident Response Archive — GitHub