افزونه‌ی آلوده‌ی Claude Code در Cursor؛ درپشتی SSH و راهنمای پاک‌سازی

نسخه‌ی ۲.۱.۳۱۳ افزونه‌ی رسمی Claude Code با نام ناشر واقعی Anthropic منتشر شد و درونش یک درپشتی SSH پنهان بود؛ Cursor می‌گوید حداکثر ۵ هزار کاربر آن را دریافت کرده‌اند.

۱. ماجرا چیست؟

روز پنجشنبه ۲۹ اکتبر ۲۰۲۶ نسخه‌ی ۲.۱.۳۱۳ افزونه‌ی anthropic.claude-code برای VS Code منتشر شد. ظاهر ماجرا عادی بود: ناشر همان Anthropic بود، شماره‌ی نسخه پشت سر نسخه‌ی ۲.۱.۳۱۲ می‌آمد و باقی بسته با نسخه‌ی سالم تفاوتی نداشت. اما به گزارش شرکت امنیتی StepSecurity، درون فایل اصلی افزونه یک بارگذار مخرب جاسازی شده بود.

مهم‌ترین نکته این است که این یک افزونه‌ی جعلی با نام مشابه نبود. نسخه‌ی آلوده زیر هویت ناشر واقعی منتشر شد و هنوز به‌طور عمومی روشن نشده که مهاجم چطور موفق به انتشار آن شده است. به همین دلیل بسیاری از کاربران که معمولاً فقط نام ناشر را بررسی می‌کنند، هشداری ندیدند. اگر دنبال تصویر کلی‌تر از این شرکت هستید، مقاله‌ی آشنایی با OpenAI و رقبای آن می‌تواند زمینه‌ی خوبی بدهد.

۲. خط زمانی رخداد

بر اساس گزارش‌های منتشرشده، نسخه‌ی سالم ۲.۱.۳۱۲ در ۲۷ اکتبر منتشر شده بود. نسخه‌ی مخرب حدود ساعت ۰۹:۲۷ به وقت UTC روز ۲۹ اکتبر در دسترس قرار گرفت. حدود ساعت ۲۰:۳۵ همان روز، Cursor نسخه را از بازار خود برداشت و بازار افزونه‌هایش را موقتاً آفلاین کرد. بعدتر بررسی‌ها نشان داد افزونه‌ی دستکاری‌شده‌ی دیگری وجود ندارد و کلیدهای مرتبط عوض شدند.

در ساعت ۰۱:۰۷ روز ۳۰ اکتبر نسخه‌ی سالم ۲.۱.۳۱۴ منتشر شد. در همان روز، نسخه‌ی ۲.۱.۳۱۳ از Open VSX و بازار مایکروسافت هم پاک شد و طبق گزارش StepSecurity، سرور فرمان‌وکنترل نیز با همکاری شرکت میزبان آفلاین شد. بنابراین پنجره‌ی در معرض خطر حدود ۱۱ ساعت در بازار Cursor بود، هرچند مدت دقیق برای هر کاربر به زمان نصب یا به‌روزرسانی او بستگی دارد.

۳. بدافزار دقیقاً چه می‌کرد؟

بارگذار مخرب به‌محض بارگذاری افزونه اجرا می‌شد. برای اجرا لازم نبود کاربر با Claude گفت‌وگو کند یا دستور نصب بسته‌ای را بزند؛ افزونه روی Node.js معمولی اجرا می‌شد و باز شدن آن کافی بود. کارهای اصلی بدافزار به شرح زیر بود:

• افزودن یک کلید SSH متعلق به مهاجم به فایل authorized_keys، با توضیح svc-telemetry، تا دسترسی تعاملی به سیستم قربانی ممکن شود.
• ساخت مکانیزم ماندگاری مخصوص هر سیستم‌عامل تا بدافزار پس از راه‌اندازی دوباره هم زنده بماند.
• باز کردن یک تونل SSH معکوس به زیرساخت مهاجم، که نیاز به باز بودن پورت ورودی روی دستگاه قربانی را از بین می‌برد.
• ارسال اطلاعات شناسایی میزبان از راه HTTP ساده، از جمله نام متغیرهای محیطی که شامل واژه‌هایی مثل KEY، TOKEN و SECRET بودند. این کار به مهاجم نشان می‌داد چه اعتبارنامه‌هایی روی دستگاه وجود دارد.

جمع‌آوری نام متغیرهای حساس یعنی مهاجم می‌خواست قبل از ورود دستی، قربانیان ارزشمند را فیلتر کند. توسعه‌دهنده‌ای که کلیدهای ابری یا توکن‌های انتشار بسته روی دستگاهش دارد، هدف جذاب‌تری است.

۴. نشانه‌های آلودگی و آثار ماندگاری

بر اساس تحلیل StepSecurity، آثار ماندگاری در هر سیستم‌عامل متفاوت است. در macOS یک LaunchAgent با نام com.apple.sysmond ساخته می‌شد. در ویندوز یک وظیفه‌ی زمان‌بندی‌شده با نام SysMon که هنگام راه‌اندازی با سطح دسترسی سیستم اجرا می‌شد و یک فایل sysmon.cmd در پوشه‌ی Startup وجود داشت. در لینوکس ورودی‌های cron با گزینه‌ی @reboot اضافه می‌شد.

فایل‌های کمکی هم در مسیرهایی مثل ~/.config/.smt، ~/.config/.smtk و ~/.config/smt.cmd و فایل‌های کلید موقت با پیشوند .stk_ در پوشه‌ی موقت سیستم گزارش شده است. نشانه‌ی شبکه‌ای اصلی، آدرس 134.209.82.225 است که هم برای تونل SSH و هم برای ارسال اطلاعات روی پورت ۸۰۹۹ استفاده می‌شد. این آدرس اکنون آفلاین است، اما وجود آن در لاگ‌ها می‌تواند نشانه‌ی اتصال گذشته باشد.

جست‌وجو برای رشته‌ی svc-telemetry یا آدرس بالا در بسته‌های افزونه‌های نصب‌شده، ساده‌ترین روش بررسی در سطح سازمان است. توجه کنید که خود سرویس‌های ifconfig.me و api.ipify.org مشروع هستند و دیدن آن‌ها به‌تنهایی نشانه‌ی نفوذ نیست.

۵. چه کسانی در خطرند؟

هر کسی که نسخه‌ی ۲.۱.۳۱۳ را بین ۲۹ اکتبر ساعت ۰۹:۲۷ UTC و زمان حذف آن نصب یا به‌روزرسانی کرده و ویرایشگر را باز کرده باشد، باید فرض کند در معرض خطر بوده است. Cursor عدد حداکثر ۵ هزار کاربر را اعلام کرده است. کاربرانی که نسخه‌ی ۲.۱.۳۱۲ یا ۲.۱.۳۱۴ را دارند، طبق بررسی StepSecurity سالم هستند.

این عدد در برابر میلیون‌ها توسعه‌دهنده کوچک است، اما اثرش بزرگ‌تر از تعدادش است. دستگاه یک توسعه‌دهنده معمولاً به مخزن‌های کد، سامانه‌های استقرار و کلیدهای ابری وصل است؛ یک نفوذ موفق می‌تواند به یک حمله‌ی زنجیره‌ی تأمین در سطح شرکت تبدیل شود.

۶. راهنمای گام‌به‌گام پاک‌سازی

گزارش StepSecurity تأکید می‌کند که فقط حذف افزونه کافی نیست، چون ماندگاری و کلید SSH بعد از حذف باقی می‌مانند. مراحل پیشنهادی:

1. فایل authorized_keys را برای کلیدی با توضیح svc-telemetry بررسی کنید.
2. پیش از پاک‌سازی، شواهد را نگه دارید و سپس آثار ماندگاری فهرست‌شده را حذف کنید. Cursor برای macOS و ویندوز اسکریپت‌های پاک‌سازی رسمی منتشر کرده است.
3. افزونه را حذف کنید و نسخه‌ی ۲.۱.۳۱۴ یا جدیدتر را نصب کنید.
4. همه‌ی اعتبارنامه‌های در دسترس آن دستگاه را از یک دستگاه تمیز عوض کنید: کنترل نسخه، CI/CD، ابر، SSH و توکن‌های مخزن بسته.
5. لاگ‌های SSH، پوسته، فرایندها و احراز هویت را مرور کنید. اگر تونل واقعاً متصل شده بود، بازسازی کامل میزبان توصیه می‌شود.

اگر تیم دارید

مدیران امنیت بهتر است فهرست افزونه‌های نصب‌شده روی دستگاه‌های تیم را بگیرند، به‌روزرسانی خودکار افزونه‌ها را موقتاً کنترل کنند و برای ثبت لاگ از دسترسی‌های SSH ورودی هشدار تنظیم کنند.

۶٫۵ نگاهی فنی به سازوکار حمله

افزونه‌های VS Code و ویرایشگرهای مبتنی بر آن مثل Cursor با سطح دسترسی خود کاربر اجرا می‌شوند. یعنی هر کدی که در فایل اصلی افزونه باشد، می‌تواند فایل‌های خانگی کاربر را بخواند، در پوشه‌ی تنظیمات بنویسد و فرایند جدید بسازد. هیچ جعبه‌ی شنی قوی مثل مرورگر در میان نیست. به همین دلیل مهاجم برای ورود لازم نداشت آسیب‌پذیری پیچیده‌ای پیدا کند؛ کافی بود کدش درون یک بسته‌ی مورد اعتماد اجرا شود.

انتخاب کلید SSH و تونل معکوس هم منطقی بود. با کلید SSH، مهاجم بدون رمز عبور و بدون هشدار آشکار وارد می‌شود و با تونل معکوس، ترافیک از سمت قربانی به بیرون برقرار می‌شود، یعنی فایروال‌های معمول که اتصال ورودی را مسدود می‌کنند اثری ندارند. ترکیب این دو، همراه با ماندگاری، دسترسی را مستقل از روشن یا بسته بودن ویرایشگر می‌کند.

از دید دفاعی، سه لایه مهم است: کنترل منبع افزونه‌ها، پایش تغییر در فایل‌های حساس مثل authorized_keys و محدود کردن خروج شبکه از دستگاه‌های توسعه. هیچ‌کدام به‌تنهایی کافی نیست، اما با هم احتمال دیده شدن چنین رخدادی را بالا می‌برند.

۷. چرا این رخداد مهم است؟

ابزارهای کدنویسی مبتنی بر هوش مصنوعی به ترمینال، فایل‌ها و گاهی کلیدهای شما دسترسی دارند. همین دسترسی گسترده آن‌ها را به هدفی ارزشمند برای مهاجمان تبدیل کرده است. این رخداد در ماهی رخ داد که چند گزارش دیگر هم نشان داد ابزارهای کدنویسی هوش مصنوعی سطح حمله‌ی تازه‌ای ساخته‌اند؛ برای نمونه حمله‌ی مرورگر داخلی ابزارهای کدنویسی را در گزارش حمله‌ی EMBRACE خواندیم.

نکته‌ی مهم دیگر اعتماد به نام ناشر است. وقتی خود ناشر معتبر قربانی یا مجرای حمله شود، بررسی ظاهری کافی نیست. برای کاهش خطر، افزونه‌ها را روی نسخه‌های تأییدشده قفل کنید، تازه‌ترین نسخه را بلافاصله نصب نکنید و دسترسی ویرایشگر به اعتبارنامه‌ها را محدود کنید. برای مرور کلی ریسک‌ها و محدودیت‌های فناوری، پتانسیل و محدودیت‌های واقعی هوش مصنوعی را هم ببینید.

۸. واکنش Cursor و Anthropic

Cursor نسخه‌ی آلوده را برداشت، بازار افزونه‌هایش را بررسی کرد، کلیدها را عوض کرد و اسکریپت‌های پاک‌سازی منتشر کرد. Anthropic نسخه‌ی سالم ۲.۱.۳۱۴ را در ۳۰ اکتبر منتشر کرد. تا زمان نگارش، علت دقیق دسترسی مهاجم به انتشار زیر نام ناشر رسمی به‌طور عمومی توضیح داده نشده است و ممکن است گزارش‌های بعدی جزئیات بیشتری بدهند.

برای پیگیری سایر خبرهای مشابه می‌توانید به بخش اخبار هوش مصنوعی سر بزنید. اگر تازه با ابزارهای هوش مصنوعی کار می‌کنید، آموزش‌های ChatGPT و راهنمای نوشتن پرامپت نقطه‌ی شروع خوبی هستند، و درباره‌ی نقش انسان در برابر خودکارسازی، توهم توسعه‌دهنده‌ی تنها در برابر مهندس واقعی را بخوانید.

۹. پرسش‌های پرتکرار

آیا Claude Code در ترمینال هم آلوده بود؟

بر اساس اطلاعات منتشرشده، مشکل مربوط به نسخه‌ی ۲.۱.۳۱۳ افزونه‌ی VS Code بود و نه ابزار خط فرمان. با این حال، اگر مطمئن نیستید، نسخه‌ی افزونه‌ی خود را بررسی کنید.

آیا نسخه‌ی ۲.۱.۳۱۲ امن است؟

بله، طبق بررسی StepSecurity نسخه‌های ۲.۱.۳۱۲ و ۲.۱.۳۱۴ سالم هستند. بهتر است به ۲.۱.۳۱۴ یا جدیدتر بروید.

اگر نسخه‌ی آلوده را نصب نکردم، باید نگران باشم؟

خیر، اما بررسی سریع authorized_keys و نسخه‌ی افزونه‌ها هیچ هزینه‌ای ندارد.

آیا تغییر رمز عبور کافی است؟

خیر. باید کلیدهای SSH، توکن‌های API و دسترسی‌های ابری هم عوض شوند، آن هم از دستگاهی که آلوده نیست.