في 29 أكتوبر 2026، بين الساعة 17:27 والساعة 04:35 من اليوم التالي بتوقيت بكين، استُبدل امتداد Claude Code الرسمي في متجر امتدادات Cursor بنسخة خبيثة تحتوي على باب خلفي عبر SSH. استمرت الحادثة نحو 11 ساعة، وشملت الإصدارين 2.1.312 و2.1.313 على منصتي macOS arm64 وWindows x64. ووفقًا لـ Cursor، قد يكون ما يصل إلى نحو 5,000 مستخدم قد نزّلوا النسخة الخبيثة أو حصلوا عليها عبر التحديث التلقائي.
لم تكن المشكلة إضافة مقلّدة تسللت إلى المتجر. فقد ثبّت المستخدمون الحزمة الرسمية باسم Anthropic.claude-code، وكانت واجهتها ووظائفها تبدو كالمعتاد، لذلك لم يدرك كثيرون أنهم ثبّتوا النسخة المصابة. ولهذا السبب أيضًا، لا يكفي حذف الامتداد أو تحديثه. فقد أضافت الشفرة الخبيثة مفتاح SSH عامًا، وأعدّت برنامجًا نصيًا للبقاء على الجهاز يبدأ تشغيله تلقائيًا عند الإقلاع، وأرسلت معلومات عن الجهاز إلى المهاجم. ولإتمام التنظيف، هناك ثلاث خطوات ضرورية: إزالة المفتاح، وإزالة آلية البقاء، وتغيير بيانات الاعتماد.
ما ستجده في هذا المقال: شرح من 5 خطوات يتبع ترتيب «ما الذي ستراه ← ماذا تفعل ← كيف تتأكد من النجاح». ويمكن للمطورين غير المتخصصين في الأمن اتباعه لإجراء الفحص والتنظيف في نحو نصف ساعة، بما في ذلك تغيير مفتاح APIYI.
التعليق: استمرت فترة النسخة الخبيثة نحو 11 ساعة، وكان 2.1.314 أول إصدار نظيف بعد الحادثة.
لا داعي للذعر: ماذا حدث لإضافة Claude Code المخترقة؟
لنبدأ بتوضيح الحقائق. جميع المعلومات في الجدول التالي مأخوذة من الإشعار الأمني الصادر عن Cursor والردود العلنية لموظفي Anthropic.
| البند | الحقيقة |
|---|---|
| الحادثة | عُدّلت إضافة Anthropic.claude-code في سوق إضافات Cursor، وزُرع فيها باب خلفي دائم عبر SSH |
| الإصدارات المتأثرة | 2.1.312 و2.1.313 (أضافت Cursor الإصدار 2.1.312 عند تحديث الإشعار في 30 أكتوبر) |
| المنصات | macOS (darwin-arm64) وWindows (win32-x64)؛ وتتضمن الشفرة أيضًا فرعًا خاصًا بـ Linux |
| فترة التعرّض | من 29 أكتوبر، 02:27 إلى 13:35 بتوقيت المحيط الهادئ، أي من 29 أكتوبر، 17:27 إلى 30 أكتوبر، 04:35 بتوقيت بكين |
| نطاق التأثير | تقول Cursor إن العدد يصل إلى 5,000 مستخدم كحد أقصى؛ وهذا تقدير لعدد المعرّضين، وليس عدد الإصابات المؤكدة |
| الوضع الحالي | أُزيلت الإصدارات الخبيثة؛ وعاد السوق للعمل بعد إغلاقه وإعادة بنائه وتدقيقه؛ وتقول Cursor إن مزوّد الاستضافة أوقف خادم المهاجم |
| الإصدارات السليمة | 2.1.314 هو أول إصدار سليم، وكان 2.1.316 أحدث إصدار حتى 31 أكتوبر |
التعليق: لقطة شاشة لصفحة الإشعار الأمني من Cursor (تُضاف أثناء التحرير).
عند ظهور الحادثة، انتشرت بعض المعلومات غير الدقيقة. إليك ثلاث نقاط تحتاج إلى تصحيح:
- الإصدار 2.1.312 موجود أيضًا ضمن قائمة الإصدارات المتأثرة. أعلنت Cursor في البداية عن الإصدار 2.1.313 فقط، ثم أضافت 2.1.312. إذا ثبّتّ الإصدار 2.1.312 من سوق Cursor خلال فترة التعرّض، فعليك فحص جهازك أيضًا.
- سوق Cursor Marketplace وحده هو الذي تعرّض للاختراق. ذكرت تقارير مبكرة أن Open VSX وسوق Microsoft وnpm تأثرت أيضًا، لكن هذه المعلومات صُححت لاحقًا. راجعت Socket سجلات التغييرات في المستودع ولم تجد سجلًا لنشر الإصدار 2.1.313 أو حذفه.
- الإصدار 2.1.313 لم يُنشر مطلقًا عبر قنوات Anthropic الرسمية. أوضح مهندس الأمن في Anthropic، David Dworken، أن هذا الإصدار لم يظهر في Open VSX أو سوق VS Code الرسمي أو على أي من خوادم Anthropic الرسمية. ولتجنب الالتباس في أرقام الإصدارات، انتقل الإصدار الرسمي التالي مباشرة إلى 2.1.314.
أما هوية المهاجم وكيف حصل على صلاحية النشر، فلا إجابة عنهما حتى الآن. قال Felix Rieseberg من Anthropic إن أنظمة الشركة أو حواسيب موظفيها لم تُخترق، بل استغل شخص ما صلاحية الوصول إلى سوق Cursor لنشر النسخة المعدّلة. في المقابل، لم يوضح إشعار Cursor كيف حصل المهاجم على صلاحية النشر. وكانت Cursor قد فتحت باب المساهمات العامة في Marketplace خلال أكتوبر، لكن الجهات الرسمية لم توضح ما إذا كان لذلك صلة بهذا الاختراق، ولن نفترض وجود صلة هنا. بالنسبة للمطورين، من الأفضل فحص أجهزتهم أولًا بدلًا من التخمين بشأن السبب الجذري.
لماذا يمكن أن يُدسّ كود خبيث في إضافة Claude Code الرسمية؟
قد يتساءل كثيرون: كيف يمكن أن تحتوي حزمة باسم رسمي على كود خبيث؟ لفهم ذلك، علينا أولًا معرفة كيف تعمل إضافات بيئة التطوير المتكاملة (IDE). تعمل الإضافة بصلاحيات بيئة التطوير، ويمكنها قراءة الشفرة البرمجية ومتغيرات البيئة والملفات الموجودة في مجلد المستخدم وكتابتها. كما أنها تنفّذ الشفرة بمجرد تحميلها، دون الحاجة إلى فتح نافذة حوار أو استخدامها فعليًا.
يُظهر تحليل Phorion أن الشفرة الخبيثة كانت دالة تُنفّذ فور تعريفها (IIFE)، تتألف من 66 سطرًا، وأُدرجت في بداية ملف extension.js قبل شفرة الإضافة العادية. وبمجرد أن يحمّل Node وحدة الإضافة، تعمل هذه الشفرة قبل استدعاء الدالة activate المعتادة. بلغ حجم ملف extension.js المعدّل 3,692,922 بايت، أي أكبر بنحو 7 كيلوبايت من الإصدار النظيف السابق. ولا تعتمد الشفرة على خطاف postinstall في npm؛ لذا لم تكن الحادثة تسميمًا لحزمة npm، بل تعديلًا مباشرًا للشفرة داخل حزمة تثبيت VSIX.
يمكن تشبيه الأمر بعلبة دواء من علامة موثوقة على رف رسمي، استُبدل محتواها بدواء مغشوش. الاسم والعبوة والرمز الشريطي كلها أصلية، لكن ما بداخلها ليس كذلك. ولهذا لم تنفع في هذه الحادثة النصيحة المعتادة: «تحقق من الناشر الرسمي».
التعليق: تتكون سلسلة عمل الباب الخلفي من ست خطوات، وإلغاء تثبيت الإضافة لا يوقف سوى الخطوة الأولى.
هناك ثلاثة مفاهيم خاطئة شائعة حول هذه الحادثة:
- «اسم الحزمة الرسمي يعني أنها بُنيت رسميًا»: كان اسم الحزمة وهوية الناشر رسميين، لكن Anthropic لم تنشئ هذا الإصدار. ويوجد على Open VSX أيضًا إصدار يحمل الرقم 2.1.312، وهو إصدار نظيف نُشر في 27 أكتوبر. رقم الإصدار واحد، لكن المصدر مختلف، وكذلك مستوى الأمان.
- «الإصدار 2.1.313 وحده متأثر»: الإصدار 2.1.312 الموجود في متجر Cursor كان خبيثًا أيضًا.
- «إلغاء التثبيت أو الترقية يحل المشكلة»: أوضح إعلان Cursor أن إلغاء تثبيت الإضافة وحده قد لا يكفي، لأن الحمولة الخبيثة تترك نصوصًا برمجية للاستمرارية تعمل بشكل مستقل.
فحص الباب الخلفي في إضافة Claude Code وإزالته في 5 خطوات
نفّذ الخطوات الخمس بالترتيب: الثلاث الأولى للفحص، والرابعة للتنظيف، والخامسة لإكمال المعالجة. توضّح كل خطوة ما عليك فعله وكيف تتحقق من اكتمالها.
التعليق: عملية من 5 خطوات، ولا يجوز إغفال تدوير بيانات الاعتماد في الخطوة الخامسة.
① افحص إصدار الإضافة ومصدرها. افتح لوحة الإضافات في Cursor، وابحث عن Claude Code، ثم تحقق من رقم الإصدار والناشر. بعد ذلك، افحص المجلد ~/.cursor/extensions/ في الطرفية، أو %USERPROFILE%\.cursor\extensions\ على Windows، وابحث عن مجلدات تحتوي أسماؤها على anthropic.claude-code-2.1.312 أو 2.1.313. حتى لو كنت تستخدم إصدارًا أحدث الآن، فإن بقاء مجلد لإصدار قديم يشير إلى احتمال تثبيته خلال فترة التعرض للخطر.
② افحص مفتاح svc-telemetry العام. على macOS وLinux، شغّل grep -n svc-telemetry ~/.ssh/authorized_keys. أما على Windows، فافحص كلا الملفين %USERPROFILE%\.ssh\authorized_keys وC:\ProgramData\ssh\administrators_authorized_keys. تتحقق الشفرة الخبيثة من وجود السلسلة svc-telemetry في الملف، لذا لا يكفي فحص التعليقات وحدها. يُنصح أيضًا بتشغيل ssh-keygen -lf ~/.ssh/authorized_keys لعرض بصمات جميع المفاتيح العامة، ومقارنتها واحدة تلو الأخرى ببصمة المهاجم SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.
③ افحص آليات الاستمرارية وعمليات الأنفاق. تختلف المواقع التي يجب فحصها حسب النظام:
- macOS: افحص
~/Library/LaunchAgents/com.apple.sysmond.plistو~/.config/.smtو~/.config/.smtk، وملفات.stk_*في المجلد المؤقت. يتنكر اسم LaunchAgent هذا في هيئة مكوّن من نظام Apple، لكنه في الواقع عنصر تشغيل تلقائي على مستوى المستخدم. - Windows: شغّل
schtasks /query /tn SysMonلفحص المهمة المجدولة؛ وتحقق من وجودsysmon.cmdفي مجلد بدء التشغيل، وكذلك%USERPROFILE%\.config\smt.cmdو%TEMP%\.stk_*. - Linux: شغّل
crontab -l، وابحث عن إدخالات تحتوي على@rebootوتشير إلى~/.config/.smt. - جميع الأنظمة: تحقق مما إذا كانت معاملات أي عملية
sshأوautosshتتضمن-R '*:0:localhost:22'.
| الخطوة | الإجراء | معيار التحقق |
|---|---|---|
| ① مصدر الإضافة | افحص لوحة الإضافات والمسار ~/.cursor/extensions/ |
لا توجد مجلدات للإصدارين 2.1.312 و2.1.313، والإصدار الحالي ≥ 2.1.314 |
| ② المفتاح العام | ابحث عن svc-telemetry وقارن البصمات |
لا توجد نتائج مطابقة في أيٍّ من نوعَي authorized_keys |
| ③ آليات الاستمرارية | افحص plist وSysMon وcron وعمليات النفق | الملفات غير موجودة، ولا توجد عملية ssh تحمل المعامل -R |
| ④ الإزالة | شغّل البرنامج النصي الرسمي من Cursor وحدّث الإضافة | ينتهي البرنامج برمز حالة 0، ثم لا يظهر شيء عند إعادة فحص ① و② و③ |
| ⑤ بيانات الاعتماد | بدّل بيانات اعتماد Git وCI والخدمات السحابية وSSH ومفاتيح API | بيانات الاعتماد القديمة معطّلة، ولا توجد أنشطة غير طبيعية في سجلات الاستدعاء |
④ إذا تبيّن أن جهازك مصاب، شغّل البرنامج النصي الرسمي للإزالة. إذا ظهر أي تطابق في الخطوة ② أو ③، فاتبع تعليمات إعلان Cursor. على macOS، نزّل cursor.com/static/security/claude-code-extension/remediate-macos.sh وشغّل bash remediate-macos.sh بحساب المستخدم المتأثر، وليس بحساب root. وعلى Windows، نزّل remediate-windows.ps1، وافتح PowerShell باستخدام خيار «تشغيل كمسؤول»، ثم نفّذ powershell -ExecutionPolicy Bypass -File .\remediate-windows.ps1. احصل على البرنامج النصي من موقع Cursor الرسمي فقط، ولا تستخدم أدوات «الإزالة بنقرة واحدة» مجهولة المصدر. يزيل البرنامج الإضافة الخبيثة وآليات الاستمرارية وعمليات النفق والمفتاح العام للمهاجم؛ وإذا بقيت أي آثار، فسينتهي برمز حالة غير صفري. بعد التنظيف، حدّث الإضافة إلى الإصدار 2.1.314 أو أحدث. وحتى 31 أكتوبر، يمكنك تثبيت الإصدار 2.1.316 مباشرةً.
⑤ بدّل بيانات الاعتماد. يشمل ذلك رموز GitHub وGitLab، ورموز CI/CD، ومفاتيح الوصول إلى الخدمات السحابية، ومفاتيح SSH الخاصة، ورموز npm وPyPI، بالإضافة إلى مفتاح APIYI على apiyi.com الذي أعددته على هذا الجهاز. أجرِ عملية التبديل من جهاز موثوق. وإذا أظهرت سجلات SSH أن النفق استُخدم بالفعل، فتوصي Phorion بإعادة بناء الجهاز المضيف، لأن ذلك أكثر أمانًا من تنظيف العناصر واحدًا تلو الآخر.
لماذا لا تزال بحاجة إلى فحص باب Claude Code الخلفي رغم أن معظم الأجهزة لم تُخترق؟
لنبدأ بالخبر الجيد نسبيًا. وفقًا لتحليل Phorion، احتوت الشفرة الخبيثة على أخطاء أدت إلى فشل تشغيل خدمة SSH على معظم الأجهزة.
في macOS، شغّل السكربت الأمر systemsetup -getremotelogin بصلاحيات مستخدم عادي، فتلقى رسالة تفيد بأن العملية تتطلب صلاحيات المسؤول، رغم أن رمز الخروج ظل 0. وكان السكربت يتحقق فقط مما إذا كانت المخرجات تحتوي على Off. ولأن الرسالة لا تتضمن هذه الكلمة، افترض خطأً أن تسجيل الدخول عن بُعد مفعّل بالفعل، وتخطى خطوة تشغيل SSH. أما في Windows، فقد أُسند أمر PowerShell الخاص بتثبيت OpenSSH Server إلى دالة مساعدة تحتوي على المسار /bin/sh ثابتًا في شفرتها. وبما أن Windows القياسي لا يحتوي على هذا المسار، فمن المرجح أن هذه الخطوة فشلت. وذكرت Cursor أيضًا أن تشغيل خدمة SSH وإنشاء النفق سيفشلان ما لم يكن Cursor يعمل بصلاحيات المسؤول، وهي حالة نادرة.
لكن هذا لا يعني زوال الخطر. فقد وُضع المفتاح العام وسكربت الاستمرارية وشفرة إرسال إشارة الاستطلاع على الأجهزة بالفعل. ولتوضيح الأمر بمثال: تعطلت أداة المهاجم لفتح الأقفال، فلم تُفتح أبواب كثيرة؛ لكن المفتاح ما زال في القفل، وتُعاد المحاولة كل 60 ثانية.
| الفئة | المؤشر (IOC، عُطّل لتجنب النقر عليه بالخطأ) | التوضيح |
|---|---|---|
| الشبكة | 134[.]209[.]82[.]225:22، اسم المستخدم tunnel |
وجهة نفق SSH العكسي |
| الشبكة | 134[.]209[.]82[.]225:8099/beacon |
إشارة HTTP غير مشفرة تُرسل معلومات الجهاز |
| المفتاح العام | التعليق svc-telemetry |
يُكتب في authorized_keys |
| البصمة | SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk |
بصمة المفتاح العام للمهاجم |
| المفتاح الخاص بالنفق | SHA256:KOAU57+ZG6u3MG4WwzPzPX2O5YEe9qdOC1Bl+6MVyDQ |
يُكتب في ملف .stk_* داخل المجلد المؤقت |
| الملف | يبدأ تجزئة SHA-256 لملف extension.js بـ ecb58cb2 |
الملف الرئيسي للإضافة الخبيثة، والقيمة الكاملة متاحة في إعلان Cursor |
التسمية التوضيحية: لقطة شاشة لجدول تجزئات VSIX الخبيث (تُضاف اللقطة أثناء التحرير).
انتبه بشكل خاص إلى الحالات التالية:
- كان تسجيل الدخول عن بُعد مفعّلًا بالفعل. إذا سبق لك تفعيل تسجيل الدخول عن بُعد على Mac من «إعدادات النظام ← عام ← المشاركة»، أو أظهر الأمر
Get-Service sshdعلى Windows أن الخدمة قيد التشغيل، فهذا يعني أن الباب الخلفي توفرت له شروط العمل. - توقف الخادم لا يعني أن الجهاز أصبح آمنًا. خادم المهاجم متوقف حاليًا، لكن برنامج الاستمرارية النصي سيواصل محاولة الاتصال. وإذا لم تُزل آثاره، فسيظل الجهاز في حالة غير آمنة.
- تحقّق من سجلات تسجيل الدخول عبر SSH. على macOS، يمكنك تشغيل
log show --predicate 'process == "sshd"' --last 7d؛ وعلى Linux، راجع/var/log/auth.log؛ وعلى Windows، راجع سجلات OpenSSH/Operational في عارض الأحداث. ابحث خصوصًا عن عمليات مصادقة ناجحة بالمفتاح العام لـ svc-telemetry من127.0.0.1أو::1. إذا وجدت سجلًا واحدًا، فتعامل مع الجهاز على أنه تعرّض لدخول غير مصرح به، وفكّر في إعادة بنائه.
جمعت الشفرة الخبيثة أيضًا اسم المضيف، واسم المستخدم، ومعلومات النظام، ودليل العمل، والبريد الإلكتروني العام المُعدّ في Git، وعنوان IP العام، وأسماء ما يصل إلى 40 متغير بيئة. وخلاصة Phorion واضحة: قلّل الخلل البرمجي احتمال تسجيل المهاجم الدخول، لكن لا يمكن الاعتماد عليه كخط دفاع.
هل يجب تغيير مفتاح APIYI بعد تلويث إضافة Claude Code؟
نعم، يجب تغييره. جمعت الشيفرة الخبيثة أسماء متغيرات البيئة التي تطابق KEY أو TOKEN أو SECRET أو PASS أو AWS أو GCP. ورغم أنها لم تقرأ قيم المتغيرات مباشرةً، فإن المهاجم أصبح يعرف بيانات الاعتماد الموجودة على جهازك. وإذا أصبح النفق متاحًا، فسيتمكن من قراءة قيم متغيرات البيئة وملفات الإعدادات وسجل أوامر shell تفاعليًا. لذلك، إذا كان الإصدار 2.1.312 أو 2.1.313 مثبتًا على جهازك خلال الفترة المتأثرة، فيجب التعامل مع مفتاح APIYI على apiyi.com المُعدّ عليه باعتباره «ربما انكشف».
للتوضيح: لم تتعرض APIYI للاختراق، لكن هناك خطر غير مباشر يتمثل في إمكانية قراءة المفتاح على جهازك. المطلوب هو استبدال المفتاح، وليس هناك داعٍ للذعر. إليك الخطوات:
| الخطوة | الإجراء | التحقق |
|---|---|---|
| 1 | افتح صفحة الرموز في لوحة التحكم api.apiyi.com/token |
تظهر قائمة المفاتيح الحالية |
| 2 | اضغط على «إضافة» في الزاوية العلوية اليمنى، واختر المجموعة ClaudeCode للمفتاح المستخدم مع Claude Code |
يُنشأ مفتاح جديد يبدأ بـ sk- |
| 3 | غيّر ANTHROPIC_AUTH_TOKEN إلى المفتاح الجديد، وأبقِ ANTHROPIC_BASE_URL على https://api.apiyi.com |
حدّث أيضًا قسم env في ~/.claude/settings.json |
| 4 | أعد فتح الطرفية وأعد تشغيل Claude Code | تعمل المحادثة والاستدعاءات بشكل طبيعي |
| 5 | عُد إلى صفحة الرموز وعطّل المفتاح القديم أو احذفه | تصبح حالة المفتاح القديم «معطّل» |
| 6 | راجع سجل الاستدعاءات | لا يوجد استهلاك مرتبط بنماذج غير معتادة أو في أوقات غير معتادة |
إذا كانت سكربتاتك تستخدم واجهة متوافقة مع OpenAI، فتذكّر أيضًا استبدال المفتاح المرتبط بـ base_url="https://api.apiyi.com/v1" في الشيفرة. بعد ذلك، أرسل طلبًا تجريبيًا بالمفتاح الجديد للتأكد من عمله. وإذا كان المفتاح القديم مستخدمًا على أجهزة أو في مشاريع أخرى، فاستبدله في كل منها، ولا تكتفِ بتغييره على جهاز واحد.
🎯 أفضل ممارسة: تتيح صفحة الرموز في APIYI على apiyi.com تحديد سقف للرصيد ومدة صلاحية لكل مفتاح. يُنصح بتخصيص مفتاح لكل جهاز، وفصل مفاتيح التطوير عن مفاتيح الإنتاج. بهذه الطريقة، إذا وقع حادث مشابه مستقبلًا، فلن تحتاج إلا إلى تعطيل المفتاح المعني.
ونؤكد مجددًا: لا يقتصر الاستبدال على مفتاح APIYI. يجب أيضًا استبدال رموز GitHub / GitLab، ومفاتيح CI، ومفاتيح الوصول لدى مزودي الخدمات السحابية، ومفاتيح SSH الخاصة، ورموز npm / PyPI. واحرص على إجراء ذلك من جهاز موثوق.
الأسئلة الشائعة حول اختراق إضافة Claude Code
س1: هل أتأثر إذا كنت أستخدم سوق VS Code الرسمي فقط؟
لا توجد حاليًا أدلة على ذلك. مصدر التوزيع الوحيد الذي أمكن التحقق منه هو Cursor Marketplace، ولم يظهر الإصدار الخبيث 2.1.313 في سوق Microsoft أو Open VSX.
س2: هل أتأثر إذا كنت أستخدم Claude Code CLI فقط، دون إضافة IDE؟
لن تتأثر بسبب هذه الحادثة. لم تُحقن حزمة CLI على npm بشيفرة خبيثة؛ المتأثر هو ملف VSIX الخاص بالإضافة في سوق Cursor فقط.
س3: هل أتأثر إذا كنت أستخدم Cursor لكنني لم أثبّت إضافة Claude Code؟
لا. لا تُنفّذ الشيفرة الخبيثة إلا عند تحميل هذه الإضافة. إذا لم تكن متأكدًا، يمكنك البحث عن `svc-telemetry` وفق الخطوة ②؛ يستغرق التحقق بضع ثوانٍ.
س4: هل يكفي التحديث إلى 2.1.314 لأكون آمنًا؟
التحديث يمنع الإصابة مستقبلًا فقط. لن تختفي المفاتيح العامة أو سكربتات البقاء التي زُرعت بالفعل، ولن تُستعاد المعلومات المسرّبة بسبب التحديث. لا تزال بحاجة إلى اتباع الخطوات ②③④⑤.
س5: هل ينبغي تثبيت الإصدار 2.1.316 الآن؟
نعم. حتى 31 أكتوبر، كان 2.1.316 أحدث إصدار على GitHub Releases، وكل من 2.1.314 و2.1.316 إصدار نظيف. عدم وجود 2.1.315 بينهما أمر طبيعي.
س6: هل أحتاج إلى إعادة تثبيت النظام؟
إذا اقتصر التأثر على المفتاح العام أو آلية البقاء، فعادةً ما يكفي تشغيل السكربت الرسمي وإجراء فحص لاحق. أما إذا أظهرت سجلات SSH أن النفق استُخدم بالفعل، فتوصي Phorion بإعادة بناء الجهاز، لأنه لا يمكن استنتاج ما فعله المهاجم بعد تسجيل الدخول من العينة وحدها.
س7: هل 5,000 هو عدد الأشخاص الذين تأكدت إصابتهم؟
لا. ذكرت Cursor أن العدد «يصل إلى 5,000 مستخدم»، وهو تقدير للتعرض بناءً على التنزيلات والتحديثات التلقائية، وليس عدد الإصابات المؤكدة. وقالت Cursor إنها ستتواصل مباشرةً مع المستخدمين المتأثرين.
س8: هل يمكن التحكم بجهازي عن بُعد؟
بسبب الخلل المذكور سابقًا، لم تُفعّل خدمة SSH على معظم أجهزة macOS وWindows، كما أن خادم المهاجم أصبح خارج الخدمة حاليًا. لكن إذا كانت ميزة تسجيل الدخول عن بُعد مفعّلة لديك مسبقًا، فالخطر حقيقي. لمعرفة ما إذا حدث تسجيل دخول، راجع سجلات SSH.
س9: هل يمكن أن يتسرب مفتاح API الخاص بي من APIYI؟
لم تُخترق منصة APIYI نفسها. يكمن الخطر في احتمال قراءة متغيرات البيئة على جهازك، لذا يُنصح بإنشاء مفتاح API جديد على api.apiyi.com/token، وتحديث الإعدادات، ثم تعطيل المفتاح القديم.
أبرز النقاط حول تسميم إضافة Claude Code
- الإصدارات المتأثرة: الإصداران 2.1.312 و2.1.313 في سوق Cursor، ولم تتأثر القنوات الرسمية الأخرى.
- التنفيذ بمجرد التحميل: لا تحتاج إلى استخدام الإضافة؛ يكفي تحميلها لزرع باب خلفي.
- ثلاثة آثار متبقية: المفتاح العام في
authorized_keys، والبرنامج النصي للاستمرارية، والمعلومات التي أرسلها كود الاتصال إلى الخارج. - لم يسجّل المهاجمون الدخول إلى أجهزة معظم المستخدمين: بسبب خطأ في الشفرة الخبيثة، لكن هذا ليس سببًا لتجاهل الفحص.
- طريقة الإزالة: شغّل البرنامج النصي الرسمي، وحدّث الإضافة إلى 2.1.314 أو أحدث، وأعِد بناء الجهاز المضيف عند الحاجة.
- تأمين بيانات الاعتماد: غيّر بيانات اعتماد Git وCI والخدمات السحابية وSSH، ومفتاح API الخاص بـ APIYI.
المراجع
- إشعار Cursor الأمني: الإصدارات المتأثرة ومؤشرات الاختراق وبرنامج الإزالة
- الرابط:
cursor.com/blog/claude-code-extension-security-notice - التحليل التقني من Phorion: تحليل الشفرة الخبيثة والخطأ فيها
- الرابط:
phorion.io/blog/offical-claude-code-vsx-compromise - تحليل StepSecurity: التحقق من السجل والإصدارات
- الرابط:
stepsecurity.io/blog/claude-code-extension-trojanized - إصدارات Claude Code على GitHub: سجل الإصدارات الرسمية
- الرابط:
github.com/anthropics/claude-code/releases
الخلاصة
ما يميز هذه الحادثة أن الإصدار الخبيث استخدم اسم الحزمة الرسمية، لذا لم يكن التحقق من الناشر الرسمي كافيًا. يُنصح باتباع هذا الترتيب: التحقق أولًا من إصدار الإضافة ومصدرها، ثم فحص المفاتيح العامة وآليات الاستمرارية. وإذا ظهرت مؤشرات إصابة، شغّل السكربت الرسمي، ثم بدّل جميع بيانات الاعتماد من جهاز موثوق. ويمكن لمستخدمي APIYI استغلال هذه الفرصة لإعادة تنظيم مجموعات المفاتيح وحصصها وفترات صلاحيتها، وفق مبدأ «مفتاح لكل جهاز». وللاطلاع على خطوات الإعداد، راجع وثائق إدارة الرموز على apiyi.com.
الكاتب: الفريق التقني في APIYI
للتواصل التقني: يمكنكم التواصل معنا عبر الصفحة الرئيسية لموقع APIYI الرسمي، والاطلاع على إعدادات ربط Claude Code في مركز الوثائق docs.apiyi.com
هذه المرة، لا يكفي تغيير الإصدار؛ فما يحتاج إلى المعالجة هو المفاتيح وآليات الاستمرارية وبيانات الاعتماد.
