كيف تعرف إن كان سارق wfx قد اشتغل في مستودعك على GitHub

ربما دفع حساب GitHub لأحد زملائك سارق أسرار إلى مستودعك هذا الأسبوع، وشغّله مرة واحدة، ثم أزاله بعد دقائق. إذا اشتغل، فكل سر وكل دور سحابي يصل إليه سير العمل (workflows) عندك صار في يد شخص آخر، وسجل التشغيل الذي كان سيخبرك بذلك قد اختفى.

تحصي Aikido Security، التي كانت أول من أبلغ عن الحملة، 4,837 حساباً مخترقاً فتحت طلبات سحب (pull requests) اختبارية في 61,764 مستودعاً، بدءاً من 10 نوفمبر. واشتغلت الحمولة (payload) في 1,806 مستودعات منها على الأقل، بحسب إحصائها.¹ ووجدت SafeDep 8,093 مستودعاً تلقّت إيداعات (commits) خبيثة بين 10 نوفمبر الساعة 12:46 بتوقيت UTC و 12 نوفمبر الساعة 04:36 بتوقيت UTC، وكانت الحملة لا تزال نشطة حين أُجري ذلك البحث.²

لماذا لم ترَ دفاعاتك المعتادة ذلك

هذا ليس طلب سحب من نسخة (fork) يملكها غريب. الإيداعات منسوبة إلى مستخدمين حقيقيين في المستودع، ببريدهم noreply ومن دون توقيع، وهذا يشير إلى رموز (tokens) مسروقة. في 1,343 مستودعاً لم يكن المؤلف هو المالك بل متعاوناً أو روبوتاً (bot).² لذلك لا يكون للإعدادات التي تحمي من النسخ، مثل الموافقة على تشغيل سير العمل الآتي من مساهمين خارجيين، أي دور هنا. المهاجم يملك صلاحية الكتابة، مثل فريقك تماماً.

النمط قصير. أولاً طلب سحب بعنوان docs: dependency audit notes من فرع wfx-docs، لاختبار صلاحية الكتابة. ثم الحمولة، في واحد من ثلاثة أشكال: نحو 1,500 سطر تُضاف إلى سير عمل موجود (ci: refresh build cache)، أو سكربت مع خطاف (hook) postinstall في npm (chore: add ci helper)، أو ملف سير عمل جديد (chore: add dependency audit workflow). ثم تراجع (revert)، ويُحذف تشغيل سير العمل مع سجلاته.¹ وأحصت SafeDep 7,309 مستودعات فيها سير العمل المحقون و 771 مستودعاً فيها خطاف npm، الذي يشتغل أيضاً على حاسوب المطور عند npm install.²

نطاق ما يأخذه واسع: أسرار Actions ومتغيراتها، و GITHUB_TOKEN، ورموز OIDC، وملفات بيانات الدخول لـ AWS و Azure و GCP و npm و PyPI و SSH، ومفاتيح أدوات الذكاء الاصطناعي. ثم يستعمل OIDC لطلب جلسات في AWS و GCP و Azure.¹ واثنتان من حركاته مصمّمتان للبقاء بعد تدوير الأسرار. على AWS يمكنه إنشاء مفاتيح وصول جديدة وإعادة كتابة سياسة الثقة لدور ما إلى "Principal": {"AWS": "*"}. وعلى Azure يضيف بيانات اعتماد موحّدة (federated credentials) باسم wfx-ci-… إلى تسجيلات التطبيقات، بحيث يبقى المستودع قادراً على تسجيل الدخول بعد تغيير كل سر.¹

ما تفعله في أول يوم عمل

ابدأ بالعلامات. يذكر التقريران كلاهما العلامات نفسها: فرع wfx-docs، وعنوان طلب السحب الاستكشافي، ورسائل الإيداع أعلاه، إضافة إلى ci: restore و ci: cleanup.² التراجع لا يحذف الإيداعات من تاريخ المستودع، لذلك يظل البحث يعثر عليها:

gh search prs --owner your-org "docs: dependency audit notes" in:title
git log --all --since=2026-11-10 --oneline \
  --grep="ci: refresh build cache" --grep="chore: add ci helper" \
  --grep="chore: add dependency audit workflow" --grep="ci: cleanup"

ثم افتح تاريخ Actions لكل سير عمل لمسه المهاجم. غياب مُخرَج (artifact) باسم wfx-loot أو ملخص WFX-BEGIN لا يعني أنك في أمان. غياب رقم التشغيل على إيداع المهاجم هو العلامة الأوثق على أن الحمولة اشتغلت.¹

إذا وجدت أي شيء، فقائمة SafeDep هي التي سأتبعها. طلب سحب استكشافي وحده يعني أن الحساب مخترق. ألغِ رموز ذلك الحساب، وأذونات OAuth، ومفاتيح SSH، وجلساته، وفعّل المصادقة الثنائية (2FA). دوّر كل سر يستطيع المستودع قراءته، بما في ذلك أسرار البيئة (environment) والمنظمة. وتعامل مع أي جهاز شغّل npm install على إيداع متأثر كجهاز مخترق.²

ثم السحابة. في Entra ID، ابحث عن بيانات اعتماد موحّدة باسم wfx-ci-* لم تنشئها أنت. وفي CloudTrail، ابحث عن جلسات باسم wfx-* يتبعها CreateAccessKey أو UpdateAssumeRolePolicy. وفي GCP، ابحث عن استدعاءات GenerateAccessToken و SignJwt من مجمّع هويات أعباء العمل (workload identity pool) الخاص بـ GitHub عندك.²

ما يساعد بعد ذلك

حين يجد فريقك وقتاً لذلك، سأقلّص ما تمنحه عبارة «أي شخص يملك صلاحية الكتابة» من حقوق. ضع أسرار النشر في بيئة (environment) على GitHub بدل المستودع. لا تستطيع المهمة (job) قراءة أسرار البيئة حتى يوافق عليها مراجع مطلوب، ويمكن حصر البيئة في فروع معينة.³ تحقق من خطة اشتراكك أولاً: في خطط Free و Pro و Team، لا يعمل المراجعون المطلوبون إلا في المستودعات العامة.³

افعل الشيء نفسه في السحابة. يقارن المزوّد موضوع (subject) رمز OIDC بالشروط المحددة على الدور، ويمكن أن يسمّي الموضوع بيئة المهمة، مثل repo:octo-org/octo-repo:environment:prod.⁴ والدور الذي لا يثق إلا بذلك الموضوع لا تصل إليه إلا المهام التي تجتاز قواعد تلك البيئة، لا سير عمل يُدفع إلى أي فرع.

وأخيراً، الفحوصات المطلوبة. تصف Aikido كوداً ينشر حالات نجاح مزيفة لتجاوز قواعد الدمج؛ ووجدته SafeDep معطّلاً في العينات التي قرأتها.² في الحالتين، يستطيع أي شخص أو تكامل (integration) يملك صلاحية الكتابة تعيين حالة. ويمكن لمجموعة قواعد (ruleset) ألا تقبل الفحص المطلوب إلا من تطبيق GitHub App محدد.⁵

المصادر

1. Aikido Security, 2026. wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories (بالإنجليزية)
2. SafeDep, 2026. wfx: GitHub Actions Credential Stealer Hits 8,000 Repos (بالإنجليزية)
3. GitHub Docs. Deployments and environments (بالإنجليزية)
4. GitHub Docs. OpenID Connect (بالإنجليزية)
5. GitHub Docs. Available rules for rulesets (بالإنجليزية)