یک افزونه قرار است کار برنامه‌نویس را راحت‌تر کند، نه راه ورود غریبه‌ها به رایانه‌اش را باز کند. هشدار تازه درباره نسخه دست‌کاری‌شده کلود کد (Claude Code) در فروشگاه کرسر (Cursor) دقیقاً به همین مرز مربوط است: نسخه‌های 2.1.312 و 2.1.313 توزیع‌شده از مسیر مشخص این فروشگاه باید بررسی شوند؛ حذف ساده افزونه، تضمین پاک‌سازی نیست.
کرسر در اطلاعیه ۲۹ اکتبر ۲۰۲۶، برابر با ۷ آبان ۱۴۰۵، و اصلاحیه ۳۰ اکتبر، نام دو نسخه را اعلام کرده است. گزارش فنی فُریون (Phorion) نیز در ۳۱ اکتبر، شنبه ۹ آبان، دامنه نسخه‌های مورد بررسی را به‌روز کرد. بنابراین کسانی که تنها هشدار اولیه درباره نسخه 2.1.313 را دیده‌اند، لازم است شماره نسخه دیگر را هم در سابقه نصب خود بررسی کنند.
چه کسانی مخاطب این هشدارند؟
اطلاعیه کرسر از بسته‌های ویندوز و مک در فروشگاه افزونه خود نام می‌برد. بازه اعلام‌شده توزیع در ۲۹ اکتبر، حدود ۲:۲۷ بامداد تا ۱۳:۳۵ به وقت تابستانی ساحل غربی آمریکا بوده است؛ معادل حدود ۱۲:۵۷ تا ۲۳:۰۵ پنجشنبه ۷ آبان به وقت تهران. نصب یا دریافت خودکار بسته از این مسیر، موضوع بررسی است؛ صرف داشتن حساب کلود، نشانه آلودگی نیست.
- نام افزونه و شماره نسخه را همراه با محل دریافت بررسی کنید.
- سابقه به‌روزرسانی خودکار را هم در نظر بگیرید؛ دانلود دستی تنها مسیر دریافت نیست.
- در رایانه سازمانی، اطلاعات نصب و هشدارها را به مسئول امنیت بدهید و شواهد را خودسرانه پاک نکنید.
این اتفاق به معنی هک همه سرویس‌های کلود نیست
گروه پژوهش امنیتی مایکروسافت (Microsoft Security Research) در گزارش ۳۰ اکتبر می‌گوید بسته‌های مخرب بررسی‌شده از فروشگاه Visual Studio مایکروسافت و مسیر رسمی بسته کلود کد در npm توزیع نشده‌اند. همین گزارش، به نقل از آنتروپیک (Anthropic)، تأکید می‌کند سامانه‌های آن شرکت نفوذ نداشته‌اند و بسته دست‌کاری‌شده ساخته آنتروپیک نبوده است.
این تفاوت برای خواندن خبر مهم است: یک نسخه آلوده با نام یک محصول معتبر، با آلوده‌بودن تمام نسخه‌های آن محصول یکی نیست. همچنین وجود نام لینوکس در تحلیل قابلیت‌های کد، به‌تنهایی اثبات نمی‌کند همه بسته‌های لینوکسی یا تمام کاربران آن آلوده شده‌اند. دامنه توزیع و توانایی بالقوه بدافزار را باید جدا خواند.
چرا پاک‌کردن افزونه ممکن است کافی نباشد؟
تحلیل کالوم هال (Calum Hall) در فریون توضیح می‌دهد کد افزوده‌شده هنگام بارگذاری بسته اجرا می‌شد و تلاش می‌کرد دسترسی از راه دور و سازوکاری برای ماندن روی دستگاه ایجاد کند. به همین دلیل، حذف پوشه افزونه الزاماً همه آثار بیرون از آن را از بین نمی‌برد.
در عین حال، پژوهشگران خطاهایی در مسیر اجرای بدافزار یافته‌اند که می‌توانسته روی بعضی دستگاه‌ها مانع دسترسی کامل مهاجم شود. این خبر خوب را نباید با گواهی سلامت رایانه اشتباه گرفت؛ باقی‌ماندن آثار مخرب و موفقیت اتصال مهاجم، دو سؤال جدا هستند.
شرکت امنیتی اکسپل (Expel) نیز در گزارش ۳۰ اکتبر از بررسی چهار رخداد در چهار مشتری، همگی روی مک، خبر داده است. به گفته این شرکت، نخستین فعالیت مخرب در یکی از موارد حدود هشت ساعت پس از پایان بازه توزیع اعلام‌شده دیده شد. این نمونه محدود، آمار کل قربانیان نیست؛ اما نشان می‌دهد بررسی فقط همان چند ساعتِ عرضه می‌تواند کافی نباشد.
اقدام امن، بدون نسخه‌های ناشناس «پاک‌سازی»
- ابتدا نسخه، منبع نصب و نشانه‌های هشدار را ثبت و بررسی کنید.
- اگر اجرای بدافزار یا نصب دسترسی غیرمجاز تأیید شد، رسیدگی را با تیم امنیت یا فرد متخصص و راهنمای رسمی همان رخداد پیش ببرید.
- پاک‌سازی آثار ماندگار و بررسی دسترسی به حساب‌ها را جدا از حذف افزونه انجام دهید؛ تغییر اعتبارنامه‌های در معرض خطر باید از دستگاه مورد اعتماد انجام شود.
مایکروسافت میان نام متغیرهای محیطی و مقدار محرمانه آن‌ها نیز تفاوت می‌گذارد: جمع‌آوری نام‌ها به‌خودی‌خود اثبات سرقت همه رمزها نیست. با این حال، رد چنین سرقتی هم بدون بررسی دستگاه ممکن نیست. نتیجه‌گیری‌های مطلق، چه «همه هک شده‌اند» و چه «با حذف افزونه همه‌چیز امن است»، از شواهد جلوتر می‌روند.
این ماجرا از نظر فنی با هشدار گواهی‌های ناامن و به‌روزرسانی ویندوز متفاوت است؛ هر رخداد راهنمای خودش را دارد. فایل یا دستور ناشناس در شبکه‌های اجتماعی را به نام رفع مشکل اجرا نکنید. پرسش خود را در بخش نظرات پایین این گزارش آسیانیوز ایران بنویسید، اما کلید دسترسی، رمز، کد محرمانه یا اطلاعات شبکه کاری را عمومی نکنید.
پرسش‌های رایج: