دليل الاستجابة لحادثة Vercel أبريل 2026

آخر تحديث: 20 أبريل 2026 @ 12:07 مساءً AEST/بريسبان - (الإصدار 2 — يتضمن تحديث الرئيس التنفيذي لـ Vercel بتاريخ 20 أبريل)

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

---

ماذا حدث؟

أعلنت Vercel في 19 أبريل 2026 أن مهاجمًا حصل على وصول غير مصرح به إلى الأنظمة الداخلية. إليك الإعلان الرسمي:

في 20 أبريل، نشر الرئيس التنفيذي لـ Vercel، Guillermo Rauch، تحديثًا مفصلاً أكد فيه مسار الوصول الأولي: استخدم موظف في Vercel منصة ذكاء اصطناعي تسمى Context.ai، والتي تم اختراقها هي نفسها؛ ومن هناك، انتقل المهاجم إلى حساب الموظف في Google Workspace ثم صعد إلى بيئات Vercel. متغيرات البيئة مشفرة عند التخزين، لكن المهاجم كان قادرًا على تعداد المتغيرات التي لم يتم وضع علامة "حساسة" عليها. يصف Vercel المهاجم بأنه متطور للغاية ومن المحتمل أن يكون مدعومًا بالذكاء الاصطناعي. Google Mandiant تشارك في الاستجابة. تذكر Vercel أن Next.js و Turbopack ومشاريعها مفتوحة المصدر لا تزال آمنة.

إليك قسم مؤشرات الاختراق المهم من هذا التنبيه الأمني:

خفيفة جدًا في التفاصيل. لا يخبرونك حتى أين تتحقق من مؤشر Google الوحيد. كعميل لـ Vercel، أنا محبط جدًا من هذا المستوى من التفاصيل. ساعدني في فهم ما الذي أبحث عنه! أخبرني أين أذهب لمعرفة ما إذا كنت قد تعرضت للاختراق أم لا!

في غياب التفاصيل من Vercel، قمنا بإنشاء هذا المستند

إذا كنت تدير أعباء عمل على Vercel، افترض ما يلي حتى يثبت العكس:

1. متغيرات البيئة غير الموسومة بأنها "حساسة" على أي مشروع Vercel في نافذة التعرض ربما كانت قابلة للقراءة.
2. أي بيانات اعتماد تم دفعها إلى Vercel عبر لوحة التحكم أو CLI vercel env والتي لم يتم تدويرها هي مسؤولية قائمة.
3. الرموز داخل مسارات تكامل Vercel ↔ GitHub و Vercel ↔ Linear ربما كانت متاحة.
4. لن تحصل على إشارة مرتبة "أنت متأثر / أنت غير متأثر" بسرعة. قم بالتدوير أولاً، ثم حقق.

---

معروف مقابل مُدّعَى: احتفظ بهذه منفصلة في إحاطاتك

هذا التمييز مهم للاتصالات التنفيذية ولتجنب الإفراط في الاستجابة (أو النقص في الاستجابة).

مؤكد من قبل Vercel (النشرة + تحديث الرئيس التنفيذي بتاريخ 20 أبريل)

• وصول غير مصرح به إلى بعض أنظمة Vercel الداخلية.
• متجه الوصول الأولي: Context.ai، وهي منصة ذكاء اصطناعي استخدمها موظف في Vercel، تم اختراقها. استخدم المهاجم نقطة الارتكاز تلك لاختراق حساب موظف Vercel في Google Workspace، ثم صعد من هناك إلى بيئات Vercel.
• متغيرات بيئة العملاء مشفرة عند التخزين. المتغيرات المصنفة على أنها "غير حساسة" كانت مع ذلك قابلة للتعداد من قبل المهاجم بمجرد دخوله.
• تأثير العميل وُصف بأنه "محدود للغاية"؛ تواصلت Vercel مباشرة مع العملاء الذين لديها مخاوف بشأنهم.
• تم تحليل Next.js و Turbopack ومشاريع Vercel مفتوحة المصدر ويُعتقد أنها لا تزال آمنة (أي لا يوجد أي قطعة خبيثة في مسار إصدار تلك المشاريع وفقًا لبيان Vercel في 20 أبريل).
• وُصف المهاجم بأنه متطور للغاية ومن المحتمل أن يكون مدعومًا بالذكاء الاصطناعي بشكل كبير.
• شركاء الاستجابة: Google Mandiant منخرط بنشاط؛ شركات استجابة خارجية، أقران في الصناعة، وجهات إنفاذ القانون متورطة.
• تواصلت Vercel مع Context.ai للمساعدة في فهم النطاق الكامل.
• قامت Vercel بشحن تحسينات واجهة المستخدم: صفحة نظرة عامة على متغيرات البيئة، إدارة محسّنة للمتغيرات الحساسة.

تم الإبلاغ عنه / نسبه من قبل أطراف ثالثة والمهاجم (غير مؤكد من قبل Vercel)

• تكاملات Linear و GitHub تأثرت بشكل غير متناسب (تقارير مجتمعية، ولا سيما Theo Browne على X).
• بيانات معروضة للبيع على BreachForums: قاعدة بيانات داخلية، حسابات موظفين، رموز GitHub، رموز npm، أجزاء من كود المصدر، طوابع زمنية للنشاط — معروضة بحوالي 2 مليون دولار.
• الفاعل يعرّف نفسه باسم ShinyHunters؛ فاعلون آخرون مرتبطون تاريخيًا بهذا اللقب نفوا التورط.
• فئات محددة من بيانات العملاء تم تسريبها تتجاوز ما أكدته Vercel مباشرة مع العملاء.

تعامل مع التقارير غير المؤكدة على أنها محتملة وقابلة للتنفيذ لفحصك الخاص، لكن لا تستشهد بها كحقيقة في اتصالات العملاء أو الجهات التنظيمية حتى تؤكدها Vercel أو يكون لديك دليل مستقل. الفجوة بين "متغيرات البيئة القابلة للتعداد" (مؤكدة من قبل Rauch) و"رموز npm + GitHub للبيع على BreachForums" (ادعاء المهاجم) هي الفجوة الأكثر أهمية لمخاطر سلسلة التوريد — افترض الأسوأ لأغراض التدوير، والتزم بالنسخة المؤكدة للاتصالات.

---

النطاق: من يحتاج إلى تشغيل هذا الدليل

أعلى أولوية — تلقيت اتصالاً مباشرًا من Vercel، أو ينطبق أي مما يلي:

• لديك (أو كان لديك) تكامل Vercel ↔ GitHub مع نطاق كتابة المستودع.
• لديك (أو كان لديك) تكامل Vercel ↔ Linear.
• تقوم بتخزين أسرار غير مشفرة (غير موسومة كحساسة) كمتغيرات بيئة Vercel.
• تنشر حزم npm من CI/CD الذي يعمل على أو من خلال بنية Vercel التحتية.

أولوية قياسية — أي فريق لديه مشاريع Vercel نشطة، حتى مواقع التسويق. غالبًا ما تحتوي مواقع التسويق على مفاتيح API لنظام إدارة المحتوى، ورموز تحليلات، ومفاتيح ويب هوك للنماذج التي تنتقل إلى أنظمة أكثر حساسية.

لا يزال يتعين القيام به — حتى لو تم حذف مشاريعك قبل الحادثة. السؤال هو ما إذا كانت الأسرار موجودة في Vercel في شكل قابل للقراءة، وليس ما إذا كان المشروع لا يزال موجودًا.

سؤال موازٍ: هل مؤسستك معرضة مباشرة لـ Context.ai؟

يذكر تحديث 20 أبريل Context.ai كمورّد معرض للخطر. إذا كان أي شخص في مؤسستك يستخدم Context.ai بشكل مستقل عن Vercel — لذكاء الاجتماعات، وإدارة المعرفة، وإثراء CRM، أو أي سير عمل آخر — فقد يكون لديك نافذة تعرض مباشرة خاصة بك منفصلة عن حادثة Vercel.

قم بتشغيل هذه الفحوصات بالتوازي:

• استعلم عن نظام الدخول الموحد / موفر الهوية (Okta, Entra, Google Workspace) عن أي مستخدم قام بالمصادقة على Context.ai أو تطبيق OAuth متعلق بـ Context.
• ابحث في وحدة تحكم إدارة Google Workspace → Security → OAuth app access logs عن context.ai أو معرفات التطبيقات المرتبطة.
• تحقق من أدوات إدارة النفقات / إدارة اشتراكات SaaS للشركات عن اشتراكات Context.ai.
• راجع نطاقات OAuth الممنوحة — نطاقات قراءة Gmail والتقويم و Drive ودليل Workspace عالية التأثير.

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

---

المرحلة 0: وقف النزيف (أول 60 دقيقة)

هدفان: منع المزيد من الضرر، والحفاظ على الأدلة.

1. جمّد عمليات النشر. أوقف عمليات النشر التلقائي على الفروع الإنتاجية. تريد منع نشر بناء معدل من قبل المهاجم، وتريد إيقاف دوران سجل التدقيق.

2. عطّل تطبيق Vercel GitHub App. إذا كان لديك تطبيق Vercel GitHub App مثبتًا، والذي سيكون موجودًا إذا كنت تقوم بنشر تلقائي إلى Vercel عند دفع كود جديد إلى GitHub. يمكنك العثور على تطبيقات GitHub المثبتة على https://github.com/organizations/<GitHub-Organization>/settings/installations

   

3. حدد الوصول الذي يمتلكه تطبيق GitHub App. انقر على زر التكوين أعلاه وتدقيق المستودعات التي كان لتطبيق Vercel حق الوصول إليها. هذا يخبرك بما تحتاج إلى التركيز عليه الآن. اذهب إلى GitHub → Organization → Settings → GitHub Apps → Vercel. راجع:

   • وصول المستودع (جميع المستودعات مقابل المختارة)
   • الأذونات الممنوحة
   • تاريخ التثبيت ومن قام بتثبيته

1. خذ لقطة لسجل تدقيق Vercel لفريقك. قم بتصديره أو التقاط شاشة فورًا. فترة الاحتفاظ محدودة وواجهة المستخدم لا تعرض كل شيء. احصل على هذا قبل البدء في إجراء تغييرات ستلوث السجل. يمكنك العثور عليه على https://vercel.com/activity-log
2. فعّل "Observability Plus". هذه ميزة إضافية مدفوعة من Vercel، ومن السيء أني مضطر لاقتراح تفعيلها والدفع مقابلها، لكن في هذه الحالة أعتقد أنها أفضل ما يمكن فعله أثناء الاستجابة للحوادث. أنا بالتأكيد لست سعيدًا بذلك، لكني قمت بتفعيلها ببساطة لأنها تحتفظ بسجلات التدقيق لفترة أطول من الافتراضية القصيرة جدًا.
3. جرد نطاق التعرض. لكل فريق / حساب Vercel تتحكم فيه، اذكر:
   • المشاريع ومستودعات Git المرتبطة بها
   • التكاملات المتصلة (GitHub App, Linear, Slack, تكاملات السوق)
   • أعضاء الفريق وأدوارهم
   • رموز الوصول الشخصية / رموز API الصادرة تحت الفريق
   • مفاتيح النشر (deploy hooks)
4. راجع سجل تدقيق مؤسسة GitHub. ابحث ****عن نافذة التعرض (بشكل متحفظ، 1–15 أبريل 2026 حتى الآن). صفّي حسب:
   • repo.add_member, repo.add_topic
   • org.invite_member, org.add_member
   • integration_installation, integration_installation.repositories_added
   • protected_branch.destroy, protected_branch.update

لا تعلن أو تقم بتدوير الأسرار بعد. تريد اللقطة أولاً.

---

المرحلة 1: التحقق من مؤشرات الاختراق (IOC)

التفاصيل من إعلان Vercel خفيفة جدًا:

على حد علمنا، يقترحون أن تذهب إلى وحدة تحكم إدارة Google Workspace الخاصة بك وتبحث عن تطبيق googleusercontent.com هذا. إليك كيفية العثور على هذا في وحدة التحكم:

1. في وحدة تحكم إدارة مساحة العمل الخاصة بك، اذهب إلى Security > Access and data control > API controls وابحث عن التطبيقات التي تم الوصول إليها والمعلقة.

   

2. ثم ابحث في القوائم المختلفة عن مؤشر الاختراق والذي هو على ما يبدو تطبيق oauth: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

   

3. إذا وجدته، قم بإزالته فورًا واستشر شريك استجابة للحوادث. هذا فوق مستواي الوظيفي.

---

المرحلة 2: تدوير بيانات الاعتماد

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

ما عليك تدويره يعتمد على ما عرضته بيئات GitHub و Vercel الخاصة بك. ابدأ بـ PATs الخاصة بـ GitHub وما إلى ذلك واعمل للخارج باستخدام هذا الدليل.

مستويات الأولوية

المستوى 0 — قم بالتدوير اليوم، قبل أي شيء آخر:

• قم فورًا بتدوير جميع PATs الخاصة بـ GitHub وإنهاء أي جلسات حالية. رموز الوصول الشخصية، أو PATs. هناك نوعان من PATs:
  • الرموز الدقيقة يمكن العثور عليها هنا: https://github.com/settings/personal-access-tokens
  • الرموز الكلاسيكية يمكن العثور عليها هنا: https://github.com/settings/tokens
• قم فورًا بتدوير أي متغيرات بيئة Vercel حساسة: http://vercel.com/all-env-vars

المستوى 1 — قم بالتدوير اليوم، اعتمادًا على ما قمت بتعريضه في تطبيقاتك:

• مفاتيح سرية لمعالج الدفع (Stripe, Adyen, Braintree, إلخ.)
• أسرار توقيع المصادقة (AUTH_SECRET / NEXTAUTH_SECRET من NextAuth، مفاتيح توقيع JWT، مفاتيح ملفات تعريف الارتباط للجلسات، رموز CSRF)
• سلاسل اتصال قاعدة البيانات مع وصول الكتابة (DATABASE_URL، عناوين URL المباشرة لـ Postgres/MySQL، URIs لـ Mongo، Redis مع المصادقة)
• مفاتيح الجذر أو النطاق الواسع لمزود السحابة (مفاتيح وصول IAM لـ AWS، ملف JSON لحساب خدمة GCP، أسرار عميل Azure)
• أسرار توقيع Webhook (Stripe, GitHub, Slack — قم بالتدوير وتحديث تكوين المرسل)

المستوى 2 — قم بالتدوير هذا الأسبوع:

• مفاتيح API لـ SaaS الطرف الثالث (التحليلات، مزودو البريد الإلكتروني، الرسائل النصية، CRM)
• أسرار عميل OAuth للتطبيقات التي تملكها
• بيانات اعتماد SMTP
• مفاتيح التشفير للتشفير على مستوى التطبيق (قم بالتدوير مع زيادة إصدار المفتاح، وليس استبدال مباشر)
• مفاتيح تطهير CDN، مفاتيح خدمة الصور
• مفاتيح مزود ميزة التبديل (feature flag)

المستوى 3 — قم بالتدوير عند الراحة، ولكن لا يزال قم بالتدوير:

• رموز تحليلات للقراءة فقط
• DSNs لـ Sentry / التسجيل (ملاحظة: تدوير DSN ليس بالغ الأهمية إذا كنت لا تمانع في نافذة صغيرة من الأحداث المفقودة)
• المفاتيح العامة والمفاتيح المجهولة (لا يزال قم بتدويرها — يمكن أن تكشف عن وجود المشروع وأحيانًا تمكين التعداد)

مشكلات تسلسل العمليات

• مفاتيح توقيع الجلسة تبطل جميع الجلسات النشطة عند التدوير. خطط لحدث تسجيل خروج إجباري. قم بإبلاغه.
• يجب تدوير أسرار Webhook في كلا الطرفين. قم بتحديث المرسل أولاً (Stripe, GitHub) للإرسال تحت السر الجديد، ثم المتلقي للتحقق ضده. أو دعم كليهما مؤقتًا.
• بيانات اعتماد قاعدة البيانات — قم بإنشاء المستخدم الجديد أولاً، وانشر، ثم قم بإلغاء القديم. لا تستبدل مباشرة أو ستتسبب في انقطاع الخدمة.
• مفاتيح AWS — إذا كنت تقوم بتدوير مفاتيح الوصول لمستخدم IAM، قم بإنشاء المفتاح الثاني، وقم بتدوير عمليات النشر، ثم احذف الأول. لا تقم بـ deactivate وأمل.
• أعد النشر بعد تغييرات متغيرات البيئة. يتم تضمين متغيرات بيئة Vercel في وقت البناء للعديد من تكوينات الإطار. تغيير متغير البيئة دون نشر جديد لا يتم تطبيقه بالكامل.
• تحقق من أسرار CI أيضًا. إذا كان السر معكوسًا في GitHub Actions أو CircleCI أو ما شابه، قم بتدوير النسخة المعكوسة.

لا تنس هذه النقاط الشائعة المفقودة

• .env.local الملتزم به في مستودع خاص (لا يزال مشكلة — ربما تم تسريب كود المصدر)
• الأسرار في بيئات معاينة / تطوير Vercel، وليس فقط الإنتاج
• الأسرار المخزنة كمتغيرات بيئة مشتركة على مستوى الفريق في Vercel
• مفاتيح النشر (deploy hooks) (قم بتدويرها؛ فهي مشغلات نشر كاملة)
• رموز الوصول الشخصية لـ Vercel الصادرة تحت حسابك
• رموز الوصول الشخصية لـ GitHub التي سمحت لتثبيت تطبيق Vercel GitHub App (منفصلة عن التطبيق نفسه)

---

المرحلة 3: الصيد على مستوى المستودع

للمستودعات التي كانت متصلة بـ Vercel:

• قارن HEAD لـ main/master مع العلامة/الالتزام الذي تعرف أنه جيد قبل نافذة الحادثة.
• ابحث عن تغييرات في:
  • package.json → scripts (خاصة postinstall, prepare, preinstall)
  • package-lock.json / pnpm-lock.yaml / yarn.lock — إضافات تبعية غير متوقعة أو زيادات إصدار
  • .github/workflows/*.yml — سير عمل جديد، خطوات run: جديدة، uses: جديدة مع SHAs غير مثبتة
  • vercel.json — تغييرات أمر البناء، إعادة كتابة/إعادة توجيه جديدة يمكنها تسريب حركة المرور

إذا كنت تنشر حزم npm من هذه المستودعات

هذا هو المكان الذي يمكن أن يصبح فيه اختراق Vercel الأولي حدثًا في سلسلة التوريد. حتى لو لم تستخدم Vercel للنشر، إذا حصل المهاجم على رمز GitHub الخاص بك وسير عمل النشر الخاص بك يستخدم هذا الرمز:

• تحقق من سجل نشر npm: npm view <pkg> time --json بحثًا عن إصدارات غير متوقعة.
• قارن tarball لكل إصدار حديث مع علامة git التي يدعي أنها تأتي منها. ينشر المهاجمون من علامة لا تتطابق مع ما هو موجود في السجل.
• دقق في استخدام NPM_TOKEN في سير العمل — قم بتدوير الرمز، وراجع من كان لديه حق الوصول.
• تحقق من إضافة مشرفين جدد إلى حزمك: npm owner ls <pkg>.
• إذا كنت تحافظ على أي شيء مهم، راقب تنفيذ سكريبت ما بعد التثبيت في tarball — قم بفك ضغطه وفحصه.

إذا وجدت دليلاً على نشر غير مصرح به، أبلغ أمان npm ([email protected]) وفكر في التقديم إلى OSV.dev. قم بإلغاء الإصدار السيئ؛ لا تقم بإلغاء النشر (إلغاء النشر محدود زمنيًا ويكسر المستهلكين في اتجاه المصب).

ملاحظة حول حزم Vercel المملوكة تحديدًا: ينص تحديث Vercel في 20 أبريل على أن Next.js و Turbopack ومشاريعهم مفتوحة المصدر تم تحليلها ويُعتقد أنها آمنة. هذا تأكيد من Vercel بشأن مسار الإصدار الخاص بهم — يجب عليك مع ذلك تدقيق حزمك كما هو مذكور أعلاه. إذا كنت تستهلك Next.js أو Turbopack، فلن تحتاج إلى التثبيت على إصدار ما قبل الحادثة كإجراء احترازي بناءً على المعلومات الحالية، ولكن راقب نشرة Vercel للتغييرات في هذا الموقف.

---

المرحلة 4: مراجعة تكامل Linear

إذا كان فريقك يستخدم تكامل Vercel ↔ Linear:

• راجع سجل تدقيق Linear (إعدادات مساحة العمل → الأمان → سجل التدقيق) لنافذة التعرض.
• ابحث عن:
  • مفاتيح API جديدة صادرة
  • تكاملات جديدة مضافة
  • تعليقات منشورة بواسطة حسابات الخدمة
  • تغييرات في وجهات webhook
  • دعوات أعضاء
  • عروض / تصدير لبيانات المشكلة (لدى التكامل وصول للقراءة إلى المشكلات، والتي غالبًا ما تحتوي على أسماء العملاء وتفاصيل الأخطاء وأحيانًا أسرار تم لصقها في التذاكر)
• قلق محدد: غالبًا ما تحتوي مشكلات Linear على أسرار ملصقة من تصحيح أخطاء المطور. قم بالبحث في مساحة عمل Linear الخاصة بك عن أنماط التسريب الشائعة (AKIA, sk_live_, ghp_, ghs_, npm_, eyJ, ----BEGIN). يجب تدوير أي شيء يتم العثور عليه.

---

المرحلة 5: مراجعة سجلات الأنظمة النهائية

يقوم تدوير بيانات الاعتماد بإلغاء استمرارية المهاجم في معظم الحالات، لكنهم ربما استخدموا الوصول بالفعل. تحقق من مستهلكي أسرارك المدورة بحثًا عن علامات الاستخدام خلال نافذة التعرض.

النوافذ للتحقق

استخدم 1 أبريل 2026 حتى الآن كحد أدنى متحفظ. تم الإعلان عن الحادثة في 19 أبريل ولكن الوصول الأولي يسبق الإعلان. إذا نشرت Vercel تاريخًا أكثر تحديدًا، سنضيق هذا وفقًا لذلك.

ما الذي تبحث عنه

• AWS CloudTrail — استدعاءات API غير عادية من مفاتيح IAM المخترقة، خاصة دفعات GetObject ضد حاويات S3، CreateUser, AttachUserPolicy, عمليات الدخول إلى وحدة التحكم من ASNs / دول جديدة.
• سجلات تدقيق قاعدة البيانات — SELECT * غير عادية على الجداول الحساسة، تصديرات كبيرة، اتصالات من عناوين IP مصدر غير متوقعة.
• سجلات Stripe / الدفع — إنشاء عملاء غير عادي، إنشاء تحويلات، إنشاء مفاتيح API.
• سجلات موفر المصادقة (Auth0, Clerk, Cognito, Firebase) — عمليات دخول مستحيلة السفر، إعادة تعيين كلمات المرور التي تم تشغيلها للمستخدمين الإداريين، تسجيلات تطبيقات جديدة.
• موفر البريد الإلكتروني (SendGrid, Postmark, إلخ.) — حملات صادرة غير متوقعة، مفاتيح API جديدة، تغييرات هوية المرسل.
• GitHub — استنساخ، إنشاء فروع، مفاتيح SSH جديدة على حسابات المستخدمين مع وصول المستودع.

بدائل مفيدة للبحث عن مؤشرات الاختراق

الصق أي أسماء مضيف أو عناوين IP يتحكم فيها المهاجم والتي نشرتها Vercel أو شركاء الاستجابة في:

• سجلات الوصول HTTP لواجهتك الأمامية (يقوم المهاجمون أحيانًا بالاستكشاف المسبق لتأكيد الوصول قبل التصرف).
• سجلات DNS — حل نطاقات غير عادية للخارج من خوادمك.
• سجلات تدفق الوكيل الصادر / VPC.

حتى وقت النشر، لم يتم إصدار أي مؤشرات اختراق من قبل Vercel. راقب نشرة Vercel وكتابات شركات الاستجابة المعروفة للتحديثات.

---

المرحلة 6: الكشف عن الاختراق المتبقي

تأخذ استمرارية المهاجم بعد اختراق طبقة المنصة عادةً هذه الأشكال. اصطاد بنشاط لكل منها:1. أعضاء الفريق الجدد أو المتعاونون في فريق Vercel الخاص بك، أو مؤسسة GitHub، أو مساحة Linear، أو حسابات السحابة. مؤرخة ضمن نافذة التعرض. 2. تفويضات OAuth جديدة على موفري SSO المتصلين (Google Workspace، Okta، Entra ID) لحسابات مطوريك. 3. تعديل تكوين CI/CD — سير عمل يتصل الآن بخوادم خارجية، أو مشغلات جديدة ذاتية الاستضافة، أو أسرار جديدة بأسماء غير مؤذية. 4. نشر غير متوقع في Vercel — تحقق من سجل النشر بحثًا عن عمليات نشر لا يمكنك ربطها بارتكاز معروف بواسطة مؤلف معروف. 5. مؤشرات الصدفة العكسية (Reverse Shell) في سجلات الدوال غير الخادمية — كتل Base64 يتم كتابتها/تنفيذها، واتصالات صادرة غير معتادة من دوال Edge/Serverless. 6. انحراف DNS — نطاقات فرعية جديدة، تغييرات CNAME، عمليات إعادة توجيه مضافة عبر vercel.json أو تكوين الإطار. 7. تغييرات المصادقة — تعطيل MFA، إعادة إنشاء رموز الاسترداد، تغيير كلمة المرور دون إجراء من المستخدم.

---

الاتصالات

داخلية

عين قائدًا للحادثة. اجتماع يومي كحد أدنى أثناء سريان التناوب. مستند واحد للحقيقة المصدرية لـ "ما قمنا بتدويره، وما هو معلق، وما وجدناه". احتفظ به خارج Linear إذا كانت Linear ضمن نطاق الحادثة — استخدم قناة جانبية.

موجهة للعملاء

استشر المستشار القانوني. تختلف عتبات الإخطار، ولكن:

• GDPR: 72 ساعة للانتهاكات القابلة للإخطار التي تؤثر على المقيمين في الاتحاد الأوروبي.
• أستراليا (نظام الإخطار بانتهاكات البيانات، OAIC): إخطار في أقرب وقت ممكن حيث من المحتمل حدوث ضرر جسيم.
• الولايات المتحدة: تختلف حسب الولاية؛ بعض الولايات لديها نوافذ تتراوح بين 30-60 يومًا، بينما تتطلب ولايات أخرى إخطارًا فوريًا لفئات بيانات محددة.
• كاليفورنيا (CCPA): التزامات محددة إذا كانت المعلومات الشخصية للمقيمين في كاليفورنيا ضمن النطاق.
• عملاء SOC 2 / ISO 27001: غالبًا ما تتطلب شروط الإخطار التعاقدية إخطارًا مبكرًا عن الحدود الدنيا التنظيمية. اقرأ اتفاقيات الخدمة الخاصة بك.

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

البيانات المعدة مسبقًا

قم بصياغة هذه قبل أن تحتاج إليها:

• اجتماع عام داخلي
• استشارة موجهة للعملاء
• قالب إخطار الجهة التنظيمية
• تحديث صفحة الحالة (إذا كانت عامة)

آداب الإسناد العلني

لا تكرر علنًا ادعاءات المهاجم كحقيقة. قم بالربط بنشرة Vercel كمصدر أساسي. دع Vercel تصف حادثتها بنفسها — أنت في مسارك الخاص لوصف تعرضك.

---

التعزيز متوسط المدى (ما بعد الحادثة)

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

• انقل جميع الأسرار إلى ميزة متغيرات البيئة الحساسة في Vercel. اجعلها الإعداد الافتراضي للفريق. درب المطورين على وضع علامة عند الإنشاء.
• اعتمد بيانات الاعتماد قصيرة العمر حيثما أمكن. استخدم اتحاد GitHub OIDC مع AWS/GCP/Azure بدلاً من مفاتيح الوصول طويلة العمر المنعكسة إلى متغيرات بيئة Vercel. استخدم مديري الأسرار السحابية الأصليين (AWS Secrets Manager، GCP Secret Manager) التي يتم الوصول إليها في وقت التشغيل بدلاً من متغيرات البيئة المضمنة.
• جرد تطبيقات OAuth الخارجية المتصلة بمساحة Google Workspace، وMicrosoft 365، ومؤسسة GitHub، وفريق Vercel الخاص بك. كانت أداة IAV في Vercel هي Context.ai — وهي منصة ذكاء اصطناعي مدمجة عبر OAuth في حساب Google Workspace لموظف. نفس فئة المخاطر موجودة في كل مؤسسة وافقت بحرية على تكاملات SaaS وأدوات الذكاء الاصطناعي، وقد انخفض معيار "ما يُوافق عليه" بشكل كبير في حمى الذهب لأدوات الذكاء الاصطناعي خلال الـ 18 شهرًا الماضية. إجراءات ملموسة:
  • اسحب تقرير تطبيق OAuth الخاص بـ Google Workspace (وحدة تحكم المشرف → الأمان → عناصر تحكم API → التحكم في الوصول إلى التطبيقات). راجع كل تطبيق له نطاقات حساسة (gmail.readonly، calendar، drive، admin.directory`).
  • افعل نفس الشيء لـ Microsoft 365 (Entra ID → تطبيقات المؤسسة).
  • فرض مراجعة ربع سنوية. اشترط موافقة أمنية لمنح OAuth الجديدة التي تحمل نطاقات حساسة.
  • فكر في تقييد تثبيت تطبيقات OAuth بقائمة مسموح بها بدلاً من الموافقة التي يقودها المستخدم.
• مبدأ الامتياز الأقل على نطاق تطبيق GitHub. إذا لم يكن Vercel بحاجة إلى الوصول إلى المستودع على مستوى المؤسسة، فقم بتقييده على المستودعات التي ينشرها فعليًا.
• تدوير نقاط الاتصال (Deploy Hooks) كروتين. ربع سنوي.
• بناء فحص أسرار في مرحلة ما قبل الالتزام و CI. Trufflehog أو gitleaks أو ما يعادلهما. امسح تاريخ المستودع بأثر رجعي بحثًا عن أي شيء قد يكون تم ارتكابه ثم تدويره — افترض أن ما تم ارتكابه مرة واحدة لا يزال موجودًا في نسخة مستنسخة في مكان ما.
• تدقيق تكوين حساب Vercel، وليس فقط الأسرار. يؤدي تدوير الرموز إلى معالجة التسريبات، لكنه يترك التعرض الهيكلي سليمًا: قيم NEXT_PUBLIC_ التي تنتهي في جانب العميل، ورموز بدون صلاحية أو نطاق، وحماية النشر متوقفة على المعاينات، واسم مستعار معلق، وخطافات ويب غير موقعة. هذه موجودة في تكوين API لـ Vercel، وليس في شجرة المصدر، لذلك يفوتها ماسحو الأسرار. أحد الخيارات مفتوحة المصدر: .

---

مراجع

• نشرة أمن Vercel: https://vercel.com/kb/bulletin/vercel-april-2026-security-incident
• تحديث Guillermo Rauch (الرئيس التنفيذي لـ Vercel) في 20 أبريل: https://x.com/rauchg/status/2045995362499076169
• وثائق متغيرات البيئة الحساسة: https://vercel.com/docs/environment-variables/sensitive-environment-variables
• سجل تدقيق Vercel: إعدادات الفريق ← سجل التدقيق
• واجهة برمجة تطبيقات سجل تدقيق GitHub: https://docs.github.com/en/rest/orgs/orgs#get-the-audit-log-for-an-organization
• جهة اتصال أمان npm: [email protected]
• مخطط NDB الخاص بـ OAIC: https://www.oaic.gov.au/privacy/notifiable-data-breaches
• تغطية BleepingComputer: https://www.bleepingcomputer.com/news/security/vercel-confirms-breach-as-hackers-claim-to-be-selling-stolen-data/

---

سجل التغييرات

• 2026-04-20 (الإصدار 2) — تم التحديث بعد بيان الرئيس التنفيذي لـ Vercel Guillermo Rauch في 20 أبريل. تم ترقية عدة عناصر من "مُبلغ عنها" إلى "مؤكدة": تم تسمية Context.ai كمورّد مخترق، وحساب Google Workspace لموظف Vercel كنقطة ارتكاز، وتعداد متغيرات البيئة غير الحساسة كحركة جانبية داخل المنصة. تمت إضافة نطاق موازٍ للتعرض المباشر لـ Context.ai. تمت إضافة بيان Vercel بأن Next.js وTurbopack والمشاريع مفتوحة المصدر تظل آمنة. تمت إضافة إشراك Mandiant. تم تعزيز توصية جرد تطبيقات OAuth.
• 2026-04-20 (الإصدار 1) — الإصدار الأولي. بناءً على نشرة Vercel بتاريخ 2026-04-19 والتقارير العامة المعاصرة. قم بالتحديث مع نشر Vercel لتفاصيل إضافية، أو مؤشرات تسوية، أو نافذة تعرض أضيق.