42 مستودعاً على GitHub اختُرقت بملفات أكبر من أن يفهرسها البحث: كيف تدقق مستودعاتك؟
اختراق 42 مستودعاً على GitHub بملفات أكبر من حدود الفهرسة وإعدادات مساعدي البرمجة: ماذا حدث، وكيف تدقق مستودعاتك وتحمي بيانات اعتمادك الآن؟
في 27 أكتوبر 2026 أعلن فريق JFrog للأبحاث الأمنية عن 42 مستودعاً على GitHub مخترَقاً بطريقة غير مألوفة: لم يخفِ المهاجمون الشيفرة الخبيثة بالتشفير وحده، بل بجعل الملفات أكبر من أن يفهرسها بحث GitHub. النتيجة أن أي فريق أمني اعتمد على خانة البحث للعثور على الأثر لم يجد شيئاً، بينما كانت الحمولة موجودة أمام عينيه. والأخطر أن الحملة استغلّت ملفات إعدادات مساعدي البرمجة بالذكاء الاصطناعي، فتحوّل فتح المستودع داخل الأداة إلى نقطة تنفيذ.
ماذا حدث بالضبط؟
بحسب ما نقله موقع InfoWorld عن JFrog، اكتُشف 42 مستودعاً تابعاً لأطراف ثالثة تحمل ملفات حمولة يصل حجم الواحد منها إلى 13.7 ميجابايت. هذا الحجم مقصود، لأنه يتجاوز حدود الفهرسة في بحث GitHub، فلا تظهر محتويات الملف في نتائج البحث عن سلاسل مشبوهة.
الحمولات كانت أغلفة ضخمة تُفكّ إلى حمولة واحدة متطابقة هدفها نشر حزم من داخل بيئة CI. وفي حالة أخرى احتوى إضافة أصلية مترجمة (native addon) على لا شيء ظاهر، لكنها تفك تشفير ملف باسم .napi_cache وقت التشغيل لتكشف الشيفرة الفعلية.
حلقة الهجوم خطوة بخطوة
- حزم npm باسم «testmetest» تمهّد للحملة وتحمل خطافات تنفيذ.
- تُوضع ملفات إعداد خاصة بأدوات مثل Claude وGemini وCursor وVS Code داخل المستودعات المخترَقة.
- عندما يفتح مطوّر المستودع داخل إحدى هذه الأدوات، تُنفَّذ الحمولة تلقائياً.
- تسرق الديدان بيانات الاعتماد، وتعبث بإعدادات CI، وتنتشر عبر سجلات الحزم.
«المشكلة ليست أن البحث ضعيف، بل أن المهاجم عرف حدود أدواتك الدفاعية وصمّم الهجوم ليقع خارجها.»
هذه الجملة خلاصة قراءتنا للحادثة وليست نصاً منقولاً، وهي تلخّص الدرس: الدفاع المبني على أداة واحدة يمكن الالتفاف عليه بمجرد معرفة حدودها.
لماذا تهمّ ملفات مساعدي البرمجة؟
حتى وقت قريب كان خطر فتح مستودع مجهول محصوراً في سكربتات التثبيت وملفات البناء. اليوم أضافت أدوات الذكاء الاصطناعي سطحاً جديداً: ملفات إعداد داخل المستودع نفسه تحدد أوامر وخطافات وخوادم أدوات (MCP) قد تعمل بمجرد الثقة بالمجلد.
| الملف | الأداة | ما الخطر إذا كان مزوَّراً؟ |
|---|---|---|
.claude/settings.json |
Claude Code | خطافات تنفّذ أوامر قبل أو بعد استخدام الأدوات |
.gemini/settings.json |
Gemini CLI | إعدادات تشغيل وأدوات غير مراجعة |
.cursor/mcp.json |
Cursor | تشغيل خادم MCP بأمر مخصّص |
.napi_cache |
إضافة أصلية | حمولة مشفّرة تُفك وقت التشغيل |
القاعدة العملية: ملفات الإعداد داخل المستودع هي شيفرة قابلة للتنفيذ، وتستحق من المراجعة ما تستحقه سكربتات البناء.
ماذا توصي JFrog بفعله؟
التوصيات التي نُقلت عن الشركة تدور حول ثلاثة محاور:
- إلغاء بيانات الاعتماد: أي مفاتيح أو رموز لـGitHub وnpm وPyPI والسحابة قد تكون وصلت إلى جهاز فتح مستودعاً مصاباً يجب إلغاؤها وإعادة إصدارها.
- تدقيق المستودعات: ابحث عن الملفات المشبوهة مثل
.claude/settings.jsonو.gemini/settings.jsonو.cursor/mcp.jsonو.napi_cache. - عدم الاعتماد على البحث: أوصت JFrog بسرد شجرة المستودع مباشرة بدل الثقة بنتائج بحث GitHub، لأن المهاجم تعمّد الالتفاف عليه.
أوامر عملية للتدقيق المحلي
يمكنك فحص نسخة مستودع محلية دون الاعتماد على أي فهرسة:
git ls-files | grep -E '(\.claude/settings\.json|\.gemini/settings\.json|\.cursor/mcp\.json|\.napi_cache)'
git ls-files -z | xargs -0 du -k 2>/dev/null | sort -rn | head -20
الأمر الأول يسرد الملفات الحساسة المتتبَّعة، والثاني يُظهر أكبر الملفات حجماً، وهو ما يكشف الأغلفة الضخمة غير المبررة.
كيف تحمي فريقك من هذا النوع من الهجمات؟
الإجراءات التالية لا تتطلب أدوات جديدة، بل انضباطاً في العمل اليومي:
- افتح المستودعات غير الموثوقة داخل حاوية أو جهاز افتراضي معزول، لا على جهازك الذي يحمل مفاتيح الإنتاج.
- لا تمنح أي مجلد «ثقة» في محررك أو مساعد البرمجة قبل مراجعة ملفات الإعداد فيه.
- استخدم رموز نشر قصيرة العمر ومحدودة الصلاحية بدل المفاتيح الدائمة.
- فعّل المصادقة الثنائية على حسابات npm وGitHub، وراقب أي فروع نشر قصيرة العمر تظهر دون سبب.
- أضف في CI فحصاً يرفض أي ملف أكبر من حد معقول (مثلاً عدة ميجابايت) داخل مستودعات الشيفرة.
أسئلة شائعة
هل فتح مستودع على GitHub يكفي لإصابة جهازي؟
ليس بالضرورة. الخطر يظهر عندما تفتح المستودع داخل أداة تنفّذ خطافات أو أوامر من ملفات إعداده بعد أن تمنحه الثقة. إن لم تمنح الثقة ولم تشغّل شيئاً، فالخطر أقل بكثير، لكن الحذر الأفضل هو العزل.
كيف أعرف أن أحد مستودعاتي متأثر؟
افحص الملفات المذكورة أعلاه في شجرة المستودع مباشرة، وراجع سجل الالتزامات بحثاً عن أوقات غير منطقية أو حسابات مختطفة، وتحقق من أي حزم npm باسم «testmetest» في الاعتماديات. وللتأكد من التفاصيل الكاملة راجع تقرير JFrog الأصلي.
هل المشكلة في GitHub أم في أدوات الذكاء الاصطناعي؟
لا يمكن تحميل طرف واحد المسؤولية. حدود الفهرسة في البحث أتاحت الإخفاء، وسهولة تنفيذ الخطافات في أدوات البرمجة جعلت الحمولة تعمل. الحل طبقات متعددة وليس إصلاحاً واحداً.
الخلاصة
اختراق 42 مستودعاً بملفات أكبر من حدود الفهرسة يذكّرنا بأن المهاجم يدرس أدواتنا الدفاعية قبل أن يهاجم. وما يجعل الحادثة مختلفة أن ملفات إعداد مساعدي البرمجة صارت جزءاً من سطح الهجوم. ابدأ اليوم بثلاث خطوات: أعد إصدار بيانات الاعتماد المعرّضة، وافحص ملفات الإعداد المذكورة بسرد الشجرة مباشرة، واعزل أي مستودع مجهول قبل فتحه في أدواتك.
المصادر: InfoWorld
