امتداد Claude Code خبيث في Cursor: كيف تحمي بيئة التطوير ووكلاء البرمجة؟

بقلم مهندس برمجيات رئيسي · LinkedIn

حُدِّث مقال أصلي

ماذا حدث لنسختي Anthropic.claude-code 2.1.312 و2.1.313 في سوق Cursor؟ تعرّف إلى خطوات الاحتواء وتدوير الأسرار وتأمين أدوات البرمجة بالذكاء الاصطناعي.

امتداد Claude Code خبيث في Cursor: كيف تحمي بيئة التطوير ووكلاء البرمجة؟

في 29 أكتوبر 2026 أعلنت Cursor اكتشاف نسختين خبيثتين تحملان الرقمين 2.1.312 و2.1.313 (لـ Windows وmacOS) من حزمة باسم Anthropic.claude-code داخل سوق إضافاتها. أكدت الشركة أن الحزمة لم تطورها Anthropic، وأنها كانت متاحة تقريبًا بين الساعة 2:27 صباحًا و1:35 ظهرًا بتوقيت المحيط الهادئ، فيما قدّرت تقارير صحفية عدد المتأثرين بما يصل إلى 5,000 مستخدم. الخطر هنا ليس في اسم أداة بعينها، بل في الثقة التي نمنحها لإضافات المحرر: فهي تعمل على جهاز يحتوي عادةً على الشيفرة المصدرية، مفاتيح Git، ملفات البيئة، وجلسات خدمات سحابية.

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

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

بحسب Cursor، كانت النسخة المعدّلة متاحة في سوق Cursor بين نحو 2:27 صباحًا و1:35 ظهرًا بتوقيت المحيط الهادئ يوم 29 أكتوبر. حاولت الشيفرة الخبيثة جمع معلومات عن الجهاز والمستخدم، منها اسم الجهاز والنظام والمعمارية ومسارات العمل وبريد Git العام وعنوان IP العام، ثم إرسال حالة الجهاز إلى خادم المهاجم.

كما حاولت إضافة مفتاح SSH غير مصرح به إلى authorized_keys، وتشغيل خدمة SSH، وفتح نفق SSH عكسي، ثم إنشاء آلية بقاء على macOS أو Windows تعيد محاولة الاتصال تقريبًا كل 60 ثانية. أوضحت Cursor أن أجزاءً من تشغيل SSH كانت ستفشل غالبًا من دون صلاحيات مدير وبسبب أخطاء في الشيفرة، لكن ذلك لا يعني أن الجهاز آمن: إضافة المفتاح وملفات البقاء وجمع البيانات قد تحدث مع ذلك.

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

احتواء الحادث ثم التعافي. عزل البيئة، إزالة الإضافة، إلغاء بيانات الاعتماد، مراجعة سجلات الوصول، استعادة بيئة نظيفة، المراقبة. إزالة الإضافة وحدها لا تلغي صلاحيات الوصول.

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

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

الترتيب العملي هو:

  1. اعزل الجهاز عن الشبكات الحساسة وأوقف استخدامه للوصول إلى الإنتاج.
  2. شغّل أدوات التحقق وسكربتات المعالجة التي نشرتها Cursor من جهاز موثوق أو وفق إجراءات فريقك.
  3. ابحث عن مؤشرات الاختراق المنشورة، ومنها تعليق مفتاح SSH باسم svc-telemetry، وملفات البقاء والمهام المجدولة والاتصالات بالعنوان المنشور في الإشعار.
  4. أزل المفتاح والملفات والعمليات، وقرر إن كان الجهاز يحتاج إلى إعادة بناء كاملة.
  5. دوّر بيانات الاعتماد والجلسات التي كان يمكن الوصول إليها من الجهاز، لكن نفّذ ذلك من جهاز نظيف.
  6. راجع سجلات Git والمنصات السحابية وCI/CD بحثًا عن نشاط غير معتاد خلال الفترة ذات الصلة.

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

لماذا تمثل إضافات وكلاء البرمجة سطح هجوم كبيرًا؟

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

بالنسبة لمهندس منتجات مستقل، قد يجتمع على جهاز واحد كود عدة عملاء، حسابات المتاجر، مفاتيح Firebase، رموز GitHub، وملفات .env. نجاح اختراق واحد قد يوسع أثره من مشروع واحد إلى أعمال كاملة. التحليل هنا لا يعني أن استخدام الوكلاء غير آمن بطبيعته؛ بل يعني أن امتيازاتهم يجب أن تتناسب مع المهمة.

سياسة بسيطة لتثبيت أدوات الذكاء الاصطناعي

1. ثبّت من قناة رسمية قابلة للتحقق

تحقق من اسم الناشر والرابط الذي توصله الوثائق الرسمية، لا من تشابه الاسم أو عدد التنزيلات وحده. تعرض Anthropic إضافة Claude Code الرسمية في Visual Studio Marketplace تحت anthropic.claude-code، كما توثق طرق تثبيت Claude Code وفحصها باستخدام claude doctor. احتفظ في دليل الفريق بقائمة قصيرة للقنوات المعتمدة بدل أن يختار كل فرد مصدرًا مختلفًا.

2. افصل البيئات حسب الحساسية

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

3. راجع التحديثات مثل أي اعتماد برمجي

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

4. راقب السلوك لا اسم الحزمة فقط

أنشئ خط أساس: ما العمليات والشبكات والملفات التي يُفترض أن تستخدمها الإضافة؟ تشغيل خدمة SSH أو إنشاء مهمة مجدولة ليس سلوكًا متوقعًا من مساعد برمجي في معظم البيئات. حلول حماية الطرفيات والسجلات المركزية مفيدة، لكن حتى المطور الفرد يستطيع مراجعة عناصر التشغيل التلقائي ومفاتيح SSH والاتصالات الخارجة دوريًا.

5. صمّم للاستجابة قبل وقوع المشكلة

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

قائمة فحص لفريق Flutter وFirebase

في مشروع Flutter، راجع خصوصًا مفاتيح توقيع Android، شهادات وملفات iOS، رموز خدمات التوزيع، وملفات إعداد Firebase. ملفا google-services.json وGoogleService-Info.plist ليسا عادةً أسرار خادم، لكن وجودهما لا يبرر كشف حسابات الخدمة أو مفاتيح Admin SDK. ضع الأسرار الفعلية خارج المستودع وقيّد أدوار IAM.

بعد حادث محتمل، شغّل الفحوص من بيئة نظيفة: راجع تغييرات pubspec.lock، ملفات CI، hooks الخاصة بـ Git، سكربتات البناء، وإعدادات المحرر المشتركة. لا تعتمد على أن git status نظيف؛ البرمجية الخبيثة قد تعيش خارج المستودع.

الخلاصة

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

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

المصادر

مقالات أخرى

شاركواتسابXLinkedIn