إضافة Claude Code الملوّثة 2.1.313: باب SSH خلفي في أداة تثق بها

في ساعات قليلة من أواخر أكتوبر 2026، وصلت نسخة مُعدَّلة من إضافة Claude Code الرسمية لمحرّر VS Code إلى متجر الإضافات في Cursor، وهي تحمل بابًا خلفيًا يفتح وصول SSH دائمًا إلى جهاز المطوّر. الحادثة لا تدور حول ثغرة في نموذج ذكاء اصطناعي، بل حول سلسلة التوريد: من ينشر الإضافة، ومن يتحقّق منها، وماذا يحدث حين تُستبدل بنسخة ملوّثة تحمل الاسم نفسه.

ماذا حدث بالضبط؟

وفق ما نشرته شركة الأمن Phorion، فإن الإصدار 2.1.313 من إضافة Claude Code احتوى على شيفرة إضافية من نحو 66 سطرًا أُضيفت في مقدّمة ملف extension.js. هذه الشيفرة تُنفَّذ بمجرد أن يحمّل Node الملف، أي قبل أن تبدأ الإضافة عملها المعتاد، ولا تحتاج إلى أن يفتح المطوّر أي محادثة أو يضغط أي زر.

بحسب إشعار Cursor، تحاول الشيفرة ثلاثة أشياء:

• إضافة مفتاح SSH يتحكّم به المهاجم إلى ملف authorized_keys.
• تشغيل خدمة SSH المحلية إن كانت متوقفة.
• فتح نفق SSH عكسي نحو خادم المهاجم، مع إرسال معلومات الجهاز وحالة الباب الخلفي إلى عنوان /beacon.

كانت النسخة متاحة في متجر Cursor نحو 11 ساعة تقريبًا، ثم استُبدلت بالإصدار 2.1.314 النظيف. تقدّر Cursor أن عدد المتأثرين لا يتجاوز 5,000 مستخدم.

الإضافة التي تحمل اسم شركة موثوقة ليست آمنة تلقائيًا؛ الثقة تنتقل من الاسم إلى قناة التوزيع، وقناة التوزيع هي الحلقة الأضعف.

من المسؤول؟ الصورة لم تكتمل بعد

بدأت التقارير الأولى بالإشارة إلى متجر Open VSX، ثم عدّلت Phorion تقديرها لاحقًا بعد إعلان Cursor، وصار المرجّح أن المصدر هو متجر إضافات Cursor نفسه. وتذكر روايات أخرى أن النسخة 2.1.313 لم تظهر أصلًا في متجر Microsoft الرسمي ولا في npm، وأن الإصدارات هناك انتقلت من 2.1.312 إلى 2.1.314 مباشرة.

أما ما نُقل عن أحد موظفي Anthropic في نقاش على Hacker News، فهو أن الحادثة لا تعني اختراقًا لأنظمة Anthropic، وأن شخصًا يملك صلاحية على متجر Cursor نشر نسخة معدّلة لم تبنِها الشركة. هذه رواية غير مباشرة، ولم نجد بيانًا رسميًا مفصّلًا يؤكدها بالكامل، لذلك نتعامل معها بحذر.

جدول: ما الذي ينبغي فحصه؟

المكوّن	ما تبحث عنه	لماذا يهم
إصدار الإضافة	هل شغّلت 2.1.313 في Cursor أو VSCodium أو VS Code؟	هو الإصدار الوحيد المعروف بأنه ملوّث
ملف ~/.ssh/authorized_keys	أي مفتاح لا تعرفه	هنا يضيف الباب الخلفي مفتاح المهاجم
خدمة SSH	هل شُغّلت دون أن تطلب ذلك؟	الشيفرة تحاول تفعيلها بنفسها
اتصالات الشبكة الصادرة	أنفاق SSH عكسية أو طلبات إلى المنفذ 8099	هذه هي قناة التحكم والإبلاغ
النافذة الزمنية	من 28 إلى 30 أكتوبر 2026 تقريبًا	هي فترة التعرّض التي تذكرها الأدلة المتداولة

لماذا لا يكفي حذف الإضافة؟

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

خطوات عملية إن كنت قد ثبّت النسخة الملوّثة

1. افصل الجهاز عن الشبكة إن كان يحتوي على أسرار حسّاسة، وأبلغ فريق الأمن في شركتك.
2. افحص authorized_keys واحذف أي مفتاح غير معروف، وراجع حالة خدمة SSH وأوقفها إن لم تكن تستخدمها.
3. راجع الاتصالات الصادرة والعمليات الجارية بحثًا عن نفق عكسي.
4. دوّر مفاتيح SSH ورموز الوصول (Tokens) ومفاتيح واجهات البرمجة التي كانت على الجهاز.
5. إن وجدت دليلًا على التشغيل، فالأسلم إعادة بناء الجهاز من نظام نظيف بدل الاكتفاء بالتنظيف.

خطوات وقائية لكل مطوّر

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

كيف يعمل الباب الخلفي خطوة بخطوة؟

فهم التسلسل يساعدك على معرفة أين تبحث عن الآثار، لأن كل مرحلة تترك أثرًا مختلفًا على الجهاز:

1. التحميل: يفتح المحرّر الإضافة فيقرأ Node ملف extension.js، وتُنفَّذ الشيفرة المضافة في أول الملف فورًا.
2. التمهيد: تتحقق الشيفرة من نظام التشغيل، وتجهّز خطوات مختلفة لكل من macOS وLinux وWindows. وقد وصفت Phorion خللًا في منطق الإعداد على macOS قد يُفشل جزءًا من التفعيل في بعض الأجهزة، وهذا يعني أن بعض المتأثرين ربما لم يُخترقوا فعليًا، لكن لا يجوز الاعتماد على هذا الاحتمال.
3. الإقامة الدائمة: تُضاف الشيفرة مفتاح المهاجم إلى authorized_keys وتحاول تشغيل خدمة SSH، فيبقى الوصول متاحًا حتى بعد إغلاق المحرّر أو إعادة تشغيل الجهاز.
4. الاتصال: يُفتح نفق عكسي إلى خادم المهاجم، وهو أسلوب يتجاوز جدران الحماية التي تمنع الاتصالات الواردة، لأن الجهاز نفسه هو من يبدأ الاتصال.
5. الإبلاغ: تُرسل معلومات الجهاز وحالة التفعيل عبر طلب HTTP إلى المنفذ 8099، ليعرف المهاجم أي الأجهزة صارت جاهزة للاستخدام.

بعد هذه المرحلة يستطيع المهاجم تقنيًا قراءة مستودعاتك وملفات البيئة .env ومفاتيح السحابة ورموز GitHub المخزّنة على الجهاز. ولهذا يوصي المختصون بتدوير الأسرار حتى لو لم تجد دليلًا قاطعًا على الاستغلال، فكلفة التدوير أقل بكثير من كلفة اختراق حساب إنتاج.

ما الذي ينبغي أن تغيّره المتاجر والشركات؟

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

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

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

لماذا تهم الحادثة أدوات الذكاء الاصطناعي تحديدًا؟

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

أسئلة شائعة

هل الحادثة تعني أن Claude Code نفسه غير آمن؟

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

كيف أعرف أنني تأثّرت؟

تحقق من الإصدار الذي كان مثبّتًا لديك في الفترة بين 28 و30 أكتوبر 2026، خصوصًا في Cursor. وإن لم تكن متأكدًا، فافحص ملف authorized_keys وخدمة SSH والاتصالات الصادرة كما في الجدول أعلاه.

هل يكفي أن أحدّث إلى 2.1.314؟

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

الخلاصة

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

المصادر: Phorion، Rietta، DoublePulsar.