فرض کنید افزونه‌ای که هر روز در ویرایشگرتان استفاده می‌کنید نسخهٔ تازه‌ای دارد. اسمش همان است، ناشرش همان، و چیزی شما را به شک نمی‌اندازد. چیزی شبیه همین سناریو در پایانِ اکتبر ۲۰۲۶ برای کاربرانِ Cursor پیش آمد. ویرایش‌های مخربِ افزونهٔ anthropic.claude-code در بازارچهٔ افزونهٔ Cursor منتشر شدند و کاربرانِ همین ویرایشگر را هدف گرفتند. این مقاله می‌گوید چه شد، چرا ماجرا بزرگ‌تر نشد و شما به‌عنوان توسعه‌دهنده کجاها باید دقت کنید.
در یک نگاه
نسخههای مخربِ افزونهٔ anthropic.claude-code (۲٫۱٫۳۱۲ و ۲٫۱٫۳۱۳) حدود ۱۱ ساعت در بازارچهٔ Cursor در دسترس بودند و تا حدود ۵٬۰۰۰ سامانه ممکن بود آنها را دانلود کرده باشند. به گزارش WIRED، خطایی در کدِ مهاجم باعث شد بارِ مخرب در بسیاری از دستگاه‌ها کامل اجرا نشود. Cursor افزونه را حذف و کلیدها را عوض کرد.
- ویرایش‌های مخربِ افزونهٔ anthropic.claude-code با شماره‌های ۲٫۱٫۳۱۲ و ۲٫۱٫۳۱۳ در بازارچهٔ Cursor منتشر شدند و حدود ۱۱ ساعت در دسترس ماندند.
- برآوردِ WIRED این است که تا حدود ۵٬۰۰۰ دستگاهِ توسعه‌دهنده ممکن بود نسخههای آلوده را دانلود کرده باشند.
- بنا به گزارش‌ها، افزونهٔ آلوده دسترسی SSH پایدار نصب می‌کرد، اطلاعاتِ میزبان و کاربر را بیرون می‌برد و اعتبارنامه‌های ابری و توکن‌های API را هدف می‌گرفت.
- به گزارش WIRED، خطا در کدِ خودِ مهاجم جلوی اجرای کاملِ بارِ مخرب را در بسیاری از سامانه‌ها گرفت؛ یعنی دلیلِ محدود ماندنِ آسیب، شانس بود و نه دفاعِ مطمئن.
- نامِ آشنا روی افزونه امنیت نمی‌آورد؛ ناشر، نسخه و دسترسی‌های افزونه را باید جداگانه سنجید.
دقیقاً چه اتفاقی افتاد؟
دو نسخهٔ مخربِ افزونهٔ anthropic.claude-code، یعنی ۲٫۱٫۳۱۲ و ۲٫۱٫۳۱۳، در بازارچهٔ افزونهٔ Cursor منتشر شدند. هدفشان کاربرانِ Cursor بود. گزارشِ SecurityWeek تاریخِ این رویداد را ۲۹ اکتبر ۲۰۲۶ ثبت کرده است.
این نسخه‌ها حدود ۱۱ ساعت در بازارچه در دسترس بودند. یازده ساعت برای یک افزونهٔ پرکاربرد کم نیست.
WIRED در گزارشِ ۳۰ اکتبر نوشت که تا حدود ۵٬۰۰۰ دستگاهِ توسعه‌دهنده ممکن بود این نسخه‌ها را دانلود کرده باشند. این عدد «برآورد» است، نه شمارِ قطعیِ آلوده‌شدگان. دانلود هم لزوماً به معنیِ آلوده‌شدنِ کامل نیست، و دلیلش را در بخشِ بعد می‌گویم.
حملهٔ زنجیرهٔ تأمین یعنی چه؟
حملهٔ زنجیرهٔ تأمین (supply chain attack) یعنی مهاجم به‌جای حمله به شما، به چیزی حمله می‌کند که شما به آن اعتماد دارید: یک افزونه، یک کتابخانه یا یک بازارچه. شما خودتان کدِ آلوده را نصب می‌کنید، آن هم از جایی که امن به نظر می‌رسد.
مثالش ساده است. اگر کسی در کارخانهٔ نان‌پزی چیزی به خمیر اضافه کند، لازم نیست در خانهٔ تک‌تکِ مشتری‌ها را بزند. مشتری‌ها نان را با خیالِ راحت می‌خرند. بازارچهٔ افزونه همان نانوایی است و افزونه همان نان.
در ابزارهای کدنویسی معمولاً افزونه‌ها نزدیک به کدِ پروژه و ابزارهای توسعه کار می‌کنند. اینکه دقیقاً به چه چیزهایی دسترسی دارند، به ابزار، تنظیمات و مجوزهای هر محیط بستگی دارد؛ برای همین سنجیدنِ دسترسیِ هر افزونه مهم است.
افزونهٔ آلوده چه کار می‌کرد؟
بنا به گزارشِ Aviatrix Threat Research، افزونهٔ آلوده سه کار می‌کرد. اول، دسترسیِ SSH پایدار نصب می‌کرد. SSH راهی است که با آن از راه دور به یک دستگاه وارد می‌شوند، و «پایدار» یعنی مهاجم راهِ ورودش را نگه می‌دارد.
دوم، اطلاعاتِ میزبان و کاربر را بیرون می‌برد؛ یعنی مشخصاتِ دستگاه و حسابِ کاربری. سوم، اعتبارنامه‌های ابری و توکن‌های API را هدف می‌گرفت. توکنِ API رمزی است که برنامه‌ها با آن به سرویس‌ها وصل می‌شوند. اگر به دست مهاجم بیفتد، او می‌تواند به نامِ شما با آن سرویس‌ها کار کند.
دقت کنید که این توضیح‌ها «بنا به گزارش‌ها» هستند و از یک منبعِ تحلیلیِ امنیتی آمده‌اند. جزئیاتِ فنی ممکن است با تحقیقاتِ بعدی دقیق‌تر شود.
چرا فاجعه بزرگ‌تر نشد؟
کوتاه‌ترین پاسخ این است که مهاجم در کدِ خودش خطا داشت. WIRED این ماجرا را «یک شانسِ خوش» توصیف کرده است. به گزارشِ WIRED، این خطا باعث شد بارِ مخرب (payload) در بسیاری از سامانه‌ها کامل اجرا نشود و اثرِ حمله محدود بماند.
«بارِ مخرب» همان بخشی از بدافزار است که کارِ اصلیِ خرابکارانه را انجام می‌دهد. اینجا بخشی از آن درست کار نکرد، پس مهاجم نتوانست در همهٔ این دستگاه‌ها کاملاً جا خوش کند.
این خبر خوب است، ولی نباید خیالتان را راحت کند. دفاعی که به اشتباهِ مهاجم تکیه دارد، دفاع نیست. دفعهٔ بعد ممکن است مهاجم کدش را درست بنویسد.
Cursor بعد از کشفِ ماجرا چه کرد؟
طبق گزارش‌ها، Cursor افزونهٔ دست‌کاری‌شده را حذف کرد و بازارچه را برای بررسی موقتاً تعلیق کرد. به گفتهٔ گزارش‌ها افزونهٔ مخربِ دیگری پیدا نشد. همهٔ کلیدها چرخانده شدند، یعنی کلیدهای قبلی باطل و کلیدهای تازه جایگزین شدند. بعد بازارچه بازسازی شد و دوباره باز شد.
این مجموعه واکنشِ درستی است: جلوی پخش را بگیر، بقیهٔ بازارچه را بگرد، اعتبارنامه‌های احتمالاً لورفته را بی‌اعتبار کن. چرخشِ کلید را همین‌جا یادتان بماند، چون در بخشِ بعد دوباره به آن می‌رسیم.
به‌عنوان توسعه‌دهنده چه چیزهایی را بسنجم؟
این بخش جمع‌بندیِ تحلیلیِ ماست، نه دستورالعملِ اجرایی. اگر نگرانید دستگاهتان نسخهٔ آلوده را داشته، تصمیم و اجرای اقدام‌هایی مثل پاکسازی، بررسی دسترسی‌های SSH یا عوضکردنِ کلیدها با متخصصِ امنیت یا تیم فناوریِ سازمانتان است. اشتباه در این کارها می‌تواند اوضاع را بدتر کند.
ولی می‌توانید خودتان چند پرسش را از افزونه‌هایتان بپرسید. جدول زیر آنها را کنار هم می‌گذارد.
- چه چیزی: ناشر افزونه · چه بپرسید: ناشرِ واقعی کیست و آیا با ناشرِ رسمیِ محصول یکی است؟ · چرا مهم است: نامِ افزونه می‌تواند آشنا باشد ولی انتشارِ آن دست‌کاری شده باشد.
- چه چیزی: نسخه و تاریخ انتشار · چه بپرسید: آیا نسخهٔ ۲٫۱٫۳۱۲ یا ۲٫۱٫۳۱۳ روی دستگاهم بوده؟ · چرا مهم است: این دو نسخه در گزارش‌ها مخرب معرفی شده‌اند.
- چه چیزی: دسترسی‌های افزونه · چه بپرسید: این افزونه واقعاً به ترمینال، شبکه و فایل‌های پروژه نیاز دارد؟ · چرا مهم است: هرچه دسترسی بیشتر، خسارتِ احتمالی بزرگ‌تر.
- چه چیزی: کلیدها و توکن‌ها · چه بپرسید: چه کلید و توکنی روی دستگاهی بود که این ویرایشگر را داشت؟ · چرا مهم است: حمله، اعتبارنامه‌های ابری و توکن‌های API را هدف می‌گرفت.
- چه چیزی: نسخههای تازه · چه بپرسید: آیا افزونه‌های حساس را پیش از نصبِ نسخهٔ تازه می‌سنجید؟ · چرا مهم است: نسخههای مخرب حدود ۱۱ ساعت در بازارچه در دسترس بودند.
ابزارهای کدنویسی هوش مصنوعی چرا سطح حملهٔ تازه‌ای‌اند؟
ابزارهای کدنویسیِ هوشمند و افزونه‌هایشان در کنارِ کدِ منبع و ابزارهای توسعه کار می‌کنند. بسته به تنظیمات و مجوزهای هر محیط، ممکن است به چیزهای حساسی مثل متغیرهای محیطی یا توکن‌های سرویس‌های ابری هم نزدیک باشند. برای مهاجم، افزونهٔ پرطرفدارِ چنین ابزاری هدفی وسوسه‌انگیز است.
نکتهٔ دیگر اعتمادِ برندی است. نامِ این افزونه، anthropic.claude-code، آشناست و کاربر کمتر شک می‌کند. این یعنی «نامِ آشنا» کافی نیست و باید ناشر، نسخه و مسیرِ انتشار را هم دید.
در این ماجرا نسخههای مخرب حدود یازده ساعت در دسترس بودند. برای ریسک‌های اینچنین بهتر است افزونه‌های نصب‌شده را محدود نگه دارید و دسترسیِ هر کدام را بسنجید. اجرای دقیقِ این کارها بسته به محیطِ شما فرق می‌کند و بهتر است با مسئولِ امنیتِ تیمتان هماهنگ شود.
پرسش‌های پرتکرار
کدام نسخههای افزونهٔ Claude Code مخرب بودند؟
طبق گزارش SecurityWeek، نسخههای ۲٫۱٫۳۱۲ و ۲٫۱٫۳۱۳ افزونهٔ anthropic.claude-code در بازارچهٔ Cursor مخرب بودند.
نسخههای مخرب چقدر در دسترس بودند؟
حدود ۱۱ ساعت. در این مدت، برآورد میشود تا حدود ۵٬۰۰۰ دستگاه ممکن بود آنها را دانلود کرده باشند.
اگر نسخهٔ آلوده را نصب کرده بودم چه کنم؟
تصمیم و اجرای پاکسازی، بررسیِ دسترسیها و عوضکردنِ کلیدها با متخصصِ امنیت یا تیم فناوریِ سازمانتان است. اول مطمئن شوید نسخهٔ نصبشدهتان کدام بوده و چه کلید یا توکنی روی آن دستگاه بوده است.
آیا این حمله روی همهٔ دستگاه‌ها کامل اجرا شد؟
نه. به گزارش WIRED، خطا در کدِ مهاجم باعث شد بارِ مخرب در بسیاری از سامانه‌ها کامل اجرا نشود و اثرِ حمله محدود بماند.
جمع‌بندی
ماجرای افزونهٔ آلودهٔ Claude Code در Cursor دو درس دارد. اول اینکه افزونه‌های ابزارهای کدنویسیِ هوشمند هدفِ جذابی‌اند و نامِ آشنا ضمانتِ امنیت نیست. دوم اینکه این بار شانس به نفعِ توسعه‌دهنده‌ها بود، چون مهاجم در کدش خطا کرده بود. دفعهٔ بعد شاید این‌طور نباشد. ناشر و نسخهٔ افزونه‌ها را بسنجید، دسترسی‌هایشان را محدود نگه دارید و اگر مشکوک شدید، پیش از هر اقدامی با متخصصِ امنیت مشورت کنید.
نظرها
هنوز نظری ثبت نشده. اولین نفری باشید که نظر می‌دهد.
نظر شما