خبر چه می‌گوید؟
مایکروسافت در گزارش امنیتی ۳۰ اکتبر ۲۰۲۶ جزئیات افزونه‌ای دستکاری‌شده با نام Claude Code را بررسی کرد که در بازار افزونه‌های Cursor عرضه شده بود. موضوع به نسخه‌های 2.1.312 و 2.1.313 شناسه anthropic.claude-code مربوط است. طبق گزارش، بسته مخرب هنگام بارگذاری تلاش می‌کرد دسترسی مبتنی بر SSH و سازوکار اجرای مجدد ایجاد کند. مایکروسافت تصریح کرده که نمونه‌های بررسی‌شده از Visual Studio Marketplace یا بسته رسمی npm توزیع نشده‌اند و Anthropic نیز نفوذ به سامانه‌های خود را تأیید نکرده است. بنابراین نام آشنای افزونه به‌تنهایی برای تعیین منشأ آلودگی کافی نیست و مسیر دریافت بسته باید در بررسی هر دستگاه مشخص شود.
این گزارش برای تیم‌های توسعه اهمیت ویژه‌ای دارد، زیرا ویرایشگر کد به مخزن، نشست‌های ابری و فایل‌های کاری نزدیک است. یک افزونه معمولاً در همان محیطی اجرا می‌شود که توسعه‌دهنده عملیات روزمره خود را انجام می‌دهد. اگر اعتماد به نام محصول جای کنترل منشأ انتشار را بگیرد، ابزار ظاهراً کمکی می‌تواند به نقطه ورود تبدیل شود. بااین‌حال، نصب نسخه مشکوک، اجرای بارگذار و موفقیت دسترسی از راه دور سه وضعیت متفاوت هستند. گزارش حاضر میان این مراحل فاصله می‌گذارد و نباید از مشاهده یک فایل نتیجه گرفت تمام قابلیت‌های مهاجم روی همان میزبان اجرا شده است. بخش‌های بعدی تحلیل دفاعی این رویداد و پیشنهادهای عملی تحریریه برای بررسی محیط سازمانی است.
چرا محل دریافت افزونه مهم است؟
شناسه یکسان در دو فروشگاه الزاماً به معنی بایت‌های یکسان نیست. تیم پاسخ‌گویی باید از روی اطلاعات نصب، کش دانلود، زمان به‌روزرسانی و مسیر مدیریت افزونه‌ها مشخص کند بسته از کدام کانال آمده است. اتکا به پرسش شفاهی از کاربر کافی نیست، زیرا بسیاری از ویرایشگرها به‌روزرسانی را خودکار انجام می‌دهند. ممکن است توسعه‌دهنده مدت‌ها پیش افزونه‌ای معتبر نصب کرده باشد اما نسخه جدید بدون اقدام مستقیم او جایگزین شده باشد. در چنین حالتی بررسی فقط تاریخ نصب اولیه، پنجره مواجهه را پنهان می‌کند. نگهداری فهرست نسخه‌ها و منشأ بسته‌ها در مدیریت دارایی توسعه، به همان اندازه ثبت نسخه مرورگر و سیستم‌عامل اهمیت دارد.
برای مثال، سازمانی با چند ویرایشگر و چند کانال توزیع باید دستگاه‌ها را بر اساس منشأ واقعی دریافت گروه‌بندی کند. یک گروه ممکن است نسخه مورد بحث را از فروشگاه آسیب‌دیده دریافت کرده باشد، گروه دوم همان نام را از کانال دیگر گرفته باشد و گروه سوم اصلاً افزونه را اجرا نکرده باشد. این تفکیک از دو خطا جلوگیری می‌کند. نخست، قرنطینه گسترده همه توسعه‌دهندگان بدون شواهد کافی؛ دوم، نادیده گرفتن میزبان آلوده به دلیل اعتماد به نام ناشر. تصمیم درباره هر گروه باید بر شواهد نصب و اجرا تکیه کند. نام تجاری در این پرونده یک سرنخ اولیه است، نه نتیجه نهایی بررسی امنیتی.
رفتار مشاهده‌شده و مرز نتیجه‌گیری
تحلیل مایکروسافت نشان می‌دهد بارگذار پیش از ادامه کار عادی افزونه، اطلاعات میزبان را جمع‌آوری می‌کرد و برای افزودن کلید، فعال کردن سرویس SSH، ایجاد تونل و ماندگاری اقدام می‌کرد. نکته مهم آن است که تلاش برای اجرای این مراحل با موفقیت آن‌ها برابر نیست. مجوز کاربر، وضعیت سرویس محلی و تنظیمات سمت دیگر اتصال بر نتیجه اثر می‌گذارند. حتی اگر تونل برقرار نشده باشد، آثار دیگری ممکن است روی دیسک باقی بماند. در نتیجه نبود یک اتصال موفق نباید بررسی فایل‌های مجوز و سازوکارهای آغاز خودکار را متوقف کند. در مقابل، حضور یک پردازش SSH نیز به‌تنهایی اثبات نفوذ نیست، زیرا توسعه از راه دور کاربرد مشروع گسترده‌ای دارد.
گزارش همچنین میان نام متغیرهای محیطی و مقدار آن‌ها تفاوت می‌گذارد. مشاهده نامی که به کلید یا توکن اشاره می‌کند، نشان می‌دهد چه نوع تنظیماتی در محیط وجود داشته است؛ این با اثبات سرقت مقدار واقعی راز برابر نیست. تیم امنیت باید در گزارش داخلی همین دقت را حفظ کند. عبارت‌هایی مانند «تمام کلیدها سرقت شدند» بدون شواهد مستقل، هم دامنه حادثه را نادرست نمایش می‌دهد و هم بازیابی را دشوار می‌کند. تصمیم برای ابطال نشست یا چرخش اعتبارنامه می‌تواند احتیاطی و مبتنی بر از دست رفتن اعتماد به میزبان باشد، اما دلیل این تصمیم باید جدا از ادعای وقوع سرقت ثبت شود.
بررسی شواهد بدون تخریب محیط توسعه
اولین گام عملی، حفظ نمونه افزونه و ثبت مشخصات آن پیش از پاک‌سازی است. زمان‌ها، مسیرها، هش فایل‌ها، کاربر اجراکننده و ارتباط میان پردازش‌ها برای بازسازی رویداد ارزش دارند. حذف فوری پوشه افزونه ممکن است بخشی از شواهد را از بین ببرد و هم‌زمان آثار خارج از آن پوشه را باقی بگذارد. بهتر است تیم پاسخ‌گویی روند مشخصی برای جمع‌آوری داشته باشد تا هر میزبان با شیوه‌ای متفاوت بررسی نشود. در سازمان کوچک نیز یک فرم ساده شامل شناسه دستگاه، منبع بسته، بازه زمانی مواجهه و نتیجه بررسی می‌تواند به تصمیم‌گیری منظم کمک کند.
در فایل‌های مجوز SSH نباید همه کلیدها به‌صورت کور حذف شوند. برخی کلیدها برای مدیریت قانونی، اتصال به محیط آزمایش یا فعالیت تیم پشتیبانی استفاده می‌شوند. روش دقیق‌تر آن است که هر ورودی مشکوک با اثرانگشت منتشرشده، تاریخ تغییر و زمینه ایجاد آن مقایسه شود. همین اصل درباره وظیفه زمان‌بندی‌شده یا سرویس آغاز خودکار نیز صدق می‌کند. نام شبیه ابزار پایش، دلیل کافی برای مشروع بودن نیست؛ نام مشابه شاخص حمله هم بدون بررسی فرمان اجرا دلیل قطعی آلودگی نیست. مقصد برنامه، مالک فایل و زنجیره ایجاد آن باید کنار یکدیگر دیده شوند تا پاک‌سازی به اختلال غیرضروری تبدیل نشود.
ماندگاری چرا با حذف افزونه تمام نمی‌شود؟
افزونه می‌تواند در خارج از مسیر نصب خود فایل بنویسد. بنابراین به‌روزرسانی ویرایشگر یا حذف بسته لزوماً تنظیمات حساب کاربر را به حالت قبل برنمی‌گرداند. این ویژگی در ارزیابی بازیابی اهمیت دارد. اگر آثار آغاز خودکار باقی بمانند، ممکن است پس از ورود دوباره یا راه‌اندازی مجدد اجرا شوند. تیم باید پس از پاک‌سازی، بازگشت آثار و رفتار شبکه را هم کنترل کند. آزمون نهایی تنها باز شدن سالم ویرایشگر نیست؛ باید اطمینان حاصل شود محیطی که توسعه‌دهنده دوباره در آن احراز هویت می‌کند، تحت کنترل باقی نمانده است.
گاهی بازسازی دستگاه از تصویر معتبر انتخاب مطمئن‌تری از حذف دستی چند فایل است، به‌خصوص وقتی داده کافی برای تعیین دامنه تغییرات وجود ندارد. این تصمیم به حساسیت نقش کاربر و دسترسی‌های او وابسته است. لپ‌تاپی که فقط مخزن عمومی را می‌خواند با دستگاهی که کلید انتشار، دسترسی تولید یا امکان امضای بسته دارد یکسان نیست. بازسازی نیز باید با بازیابی انتخابی داده همراه باشد؛ کپی بی‌بررسی همه تنظیمات قدیمی می‌تواند همان وضعیت نامطمئن را برگرداند. نقطه بازیابی باید معلوم باشد و اعتبارنامه‌های حساس از دستگاهی پاک و با ثبت زمان تغییر مدیریت شوند.
فروشگاه افزونه بخشی از زنجیره تأمین است
سیاست امنیت توسعه معمولاً روی کتابخانه‌های برنامه تمرکز دارد، اما ابزارهای توسعه نیز کد اجرا می‌کنند. افزونه، زبان‌سرور، قالب پروژه و ابزار ساخت می‌توانند همان سطح دسترسی کاربر را داشته باشند. این حادثه یادآور می‌شود فهرست اجزای مورد اعتماد باید محیط کار توسعه‌دهنده را هم پوشش دهد. در عمل می‌توان ناشران مجاز، کانال‌های دریافت و نسخه‌های حساس را تعریف کرد و برای تغییرات تازه دوره بررسی در نظر گرفت. این کار قرار نیست هر به‌روزرسانی را برای مدت نامعلوم متوقف کند؛ هدف ایجاد زمانی کوتاه و قابل اندازه‌گیری برای کشف انتشار غیرعادی و جلوگیری از گسترش فوری آن است.
تعادل میان سرعت و کنترل باید بر اساس ریسک برقرار شود. افزونه‌ای که فقط رنگ‌بندی متن را تغییر می‌دهد با ابزاری که فرمان اجرا می‌کند یا به نشست ابری دسترسی دارد تفاوت دارد. سازمان می‌تواند برای گروه دوم ثبت دقیق‌تر و بررسی سخت‌گیرانه‌تر داشته باشد. همچنین نصب افزونه آزمایشی در محیط جداگانه کمک می‌کند آزمون قابلیت تازه به حساب اصلی توسعه‌دهنده گره نخورد. این تفکیک زمانی مؤثر است که اسرار و دسترسی‌های اصلی وارد محیط آزمایش نشده باشند. جدا بودن پنجره ویرایشگر یا پوشه پروژه به‌خودی‌خود یک مرز امنیتی قابل اتکا ایجاد نمی‌کند.
پرسش‌هایی که مدیر امنیت باید پاسخ دهد
برای بستن پرونده، چهار موضوع باید روشن شود. چه دستگاه‌هایی بسته مشکوک را دریافت کردند، روی کدام دستگاه‌ها بارگذاری صورت گرفت، چه تغییرات یا ارتباطاتی مشاهده شد و چه اقدام بازیابی برای هر دستگاه انجام شده است. این پاسخ‌ها باید با مدارک قابل بررسی همراه باشند. تعداد دستگاه‌های نصب‌شده با تعداد دستگاه‌های دارای شواهد دسترسی یکسان نیست. گزارش مدیریتی اگر این دو عدد را در هم ادغام کند، شدت و گستره حادثه را مبهم خواهد کرد. همچنین باید معلوم شود داده‌های پایش از چه زمانی در دسترس بوده‌اند؛ نبود رویداد در بازه‌ای که اصلاً ثبت نشده، نشانه سالم بودن نیست.
از منظر مهندسی، درس ماندگار این پرونده ایجاد رابطه روشن میان اعتماد به ناشر، اعتماد به کانال توزیع و اعتماد به اجرای محلی است. هر سه باید جداگانه قابل سنجش باشند. تیمی که موجودی افزونه‌ها، لاگ تغییرات و مسیر پاسخ‌گویی دارد، می‌تواند پس از انتشار هشدار سریع‌تر دامنه مواجهه را محدود کند. تیمی که فقط نام محصول را می‌شناسد مجبور می‌شود با حدس تصمیم بگیرد. این خبر نه اثبات آلودگی تمام کاربران Claude Code است و نه موضوعی که با حذف ظاهری یک افزونه پایان یابد. نتیجه دقیق برای هر سازمان از بررسی نسخه، منشأ و شواهد واقعی دستگاه‌های خودش به دست می‌آید.
تأیید زنجیره انتشار و جلوگیری از نتیجه‌گیری اشتباه
در تحلیل این رویداد، منشأ دریافت بسته از خود نام افزونه مهم‌تر است. پژوهش مایکروسافت می‌گوید دو شماره نسخه آلوده از کانال فروشگاه افزونه Cursor توزیع شدند و نسخه‌ای که در فروشگاه Visual Studio یا بسته رسمی npm قرار داشت، جزو همین حادثه نبود. این تمایز برای مدیر امنیت اهمیت عملی دارد: فهرست دارایی‌ها باید علاوه بر نام افزونه، شناسه فروشگاه، زمان نصب، نسخه و منبع به‌روزرسانی را ثبت کند. در بررسی اولیه نباید همه محیط‌هایی را که نام Claude Code را نمایش می‌دهند آلوده فرض کرد. همچنین اعلام محدود بودن رخداد به یک کانال توزیع، جای آزمایش سیستم‌هایی را که آن بسته مشخص را دریافت کردند نمی‌گیرد.
Cursor در اطلاعیه مستقل خود بازه زمانی قرار گرفتن افزونه در فروشگاه را اعلام کرده است. این بازه با زمان بررسی هر دستگاه مقایسه می‌شود، اما نتیجه قطعی نیازمند شواهد نصب، بارگذاری کد و آثار روی میزبان است. پیشنهاد عملی این است که پس از بستن مسیر آلوده، روند احراز هویت ناشر، اطلاع‌رسانی به کاربران و کنترل به‌روزرسانی افزونه‌ها بازبینی شود. هدف از چنین بررسی‌ای کاهش زمان شناسایی و پاسخ به حادثه بعدی است، نه نسبت دادن شتاب‌زده همه اختلال‌های SSH به یک افزونه خاص.
