افشای حفره‌ی امنیتی در حالت خودکار Claude Code؛ اجرای کد فقط با یک خلاصه‌سازی سایت

حالت خودکار Claude Code، که قرار بود کدنویسی با هوش مصنوعی را بی‌دردسر و امن کند، با یک درخواست به‌ظاهر بی‌خطر برای خلاصه‌سازی یک وب‌سایت دور زده شد؛ گزارشی تازه نشان می‌دهد چگونه.

۱. حالت خودکار Claude Code چیست و چرا این‌قدر مهم است؟

حالت خودکار یا Auto Mode یکی از تازه‌ترین و مهم‌ترین لایه‌های ایمنی در Claude Code، محصول شرکت Anthropic برای کدنویسی عامل‌محور (agentic coding) است. پیش از این، هر بار که دستیار می‌خواست یک دستور سیستمی اجرا کند، کاربر باید آن را تأیید می‌کرد؛ کاری که کند و خسته‌کننده بود. حالت خودکار این تأییدیه‌ها را با یک کلاسیفایر هوشمند جایگزین کرد که خودش تصمیم می‌گیرد کدام دستور بی‌خطر است و کدام باید متوقف شود. این قابلیت به‌تازگی به‌صورت پیش‌فرض روی Claude Code فعال شده و بخش مهمی از استراتژی امنیتی آنتروپیک برای عامل‌های کدنویسی محسوب می‌شود.

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

۲. زنجیره‌ی حمله؛ از یک درخواست ساده تا اجرای کد دلخواه

جذاب‌ترین بخش این گزارش، سادگی نقطه‌ی شروع آن است. کاربر فقط از Claude Code می‌خواهد محتوای یک صفحه‌ی وب را برایش خلاصه کند؛ دقیقاً همان کاری که میلیون‌ها بار در روز توسط دستیارهای هوش مصنوعی انجام می‌شود. اما وب‌سایت مهاجم به‌جای پاسخ عادی، کد خطای ۴۱۵ برمی‌گرداند؛ خطایی که کلود را وادار می‌کند به‌جای ابزار معمول واکشی وب (WebFetch)، سراغ دستور خط‌فرمان curl برود.

گام به گام تا نفوذ

از این نقطه، curl با پیروی از یک تغییرمسیر HTTP کد ۳۰۳، یک فایل فشرده با نام ظاهراً بی‌خطری مثل یک کاتالوگ دفترچه دانلود می‌کند. کلود آن را در یک پوشه‌ی موقت استخراج می‌کند. درون این بایگانی یک فایل اجرایی مشکوک هم وجود دارد که کلود، به‌درستی، از اجرای مستقیم آن خودداری می‌کند؛ تا این‌جا همه‌چیز طبق انتظار پیش می‌رود و رفتار مدل کاملاً محتاطانه به نظر می‌رسد.

مشکل از جایی شروع می‌شود که کلود برای رمزگشایی محتوای همان فایل، تصمیم می‌گیرد خودش یک اسکریپت کوچک پایتون بنویسد. این اسکریپت ماژول استاندارد base64 را وارد (import) می‌کند. اما ماژول base64 به‌طور داخلی به ماژول دیگری به نام struct نیاز دارد و چون مسیر جست‌وجوی پایتون همان پوشه‌ی استخراج‌شده را هم در بر می‌گیرد، یک نسخه‌ی جعلی و مخرب از فایل struct.py که مهاجم از قبل در بایگانی جاسازی کرده بود، به‌جای ماژول اصلی بارگذاری می‌شود.

به این تکنیک «سایه‌اندازی ماژول» یا module shadowing می‌گویند. فایل مخرب struct.py طوری نوشته شده که ظاهراً همان قابلیت‌های استاندارد کتابخانه‌ی پایتون را هم ارائه می‌دهد، اما در لحظه‌ی وارد شدن، کد مبهم‌سازی‌شده‌ای را نیز اجرا می‌کند که یک مرحله‌ی بعدی را از سرور مهاجم دانلود کرده و یک کانال فرمان-و-کنترل (C2) برقرار می‌کند. به بیان خود ربرگر: «کلود به فایل اجرایی که برایش فرستاده شده بود اعتماد نکرد، اما به فایلی که خودش نوشت، اعتماد کامل داشت».

۳. پارادوکس عجیب؛ وقتی کلود خودش نفوذ را می‌بیند اما نمی‌تواند جلویش را بگیرد

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

ربرگر این وضعیت را با جمله‌ای کوتاه توصیف کرده است: «حالت خودکار فقط دستور کوتاه پایتون قابل مشاهده را می‌بیند، در حالی که سوءاستفاده‌ی واقعی چند لایه آن‌طرف‌تر رخ می‌دهد». به بیان دیگر، مکانیزم ایمنی که قرار بود از کاربر محافظت کند، در این سناریو خودش تبدیل به بخشی از مشکل شده؛ نه چون دچار خطا شده، بلکه چون اصلاً برای دیدن این نوع زنجیره‌ی چندمرحله‌ای طراحی نشده بود.

۴. نرخ موفقیت حمله چقدر بود؟

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

۵. واکنش آنتروپیک: «طبق طراحی»، نه یک باگ

پس از دریافت گزارش ربرگر، تیم امنیتی آنتروپیک آن را در دسته‌ی «اطلاع‌رسانی» (Informative) طبقه‌بندی کرد؛ نه یک آسیب‌پذیری بحرانی که نیاز به وصله‌ی فوری داشته باشد. موضع رسمی شرکت این بوده که حالت خودکار یک قابلیت رفاهی مبتنی بر یک کلاسیفایر «تلاش‌محور» (best-effort) است، نه یک تضمین امنیتی رسمی؛ و زنجیره‌های تزریق پرامپت چندمرحله‌ای که از چند اقدام به‌ظاهر بی‌خطر تشکیل شده‌اند، فراتر از دامنه‌ی طراحی اولیه‌ی این کلاسیفایر هستند.

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

۶. پارادوکس بازاریابی؛ صفر درصد در برابر یک اکسپلویت واقعی

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

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

۷. این ماجرا فقط مخصوص Claude Code نیست

مسئله‌ی امنیت عامل‌های کدنویسی هوش مصنوعی محدود به یک شرکت نمی‌شود. چند هفته پیش از این گزارش، پژوهشی مستقل از سوی انجمن Cloud Security Alliance نشان داده بود که یک ایشوی مخرب ساده در گیت‌هاب می‌تواند هم Claude Code و هم Gemini CLI گوگل را وادار به اجرای دستور روی سرورهای CI/CD کند و رمزهای حساسی مانند توکن گیت‌هاب یا کلید API را افشا کند؛ آسیب‌پذیری Gemini CLI حتی امتیاز کامل ده از ده در معیار CVSS گرفت. در همان بازه، ابزار Codex شرکت OpenAI نیز با ضعف دیگری در جریان کاری چندمرحله‌ای‌اش شناسایی شد که به یک عامل با دسترسی محدود اجازه می‌داد فایل‌های دستوری جعلی بسازد که بعداً توسط یک عامل با دسترسی بالاتر، معتبر تلقی می‌شدند.

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

۸. چگونه از عامل‌های کدنویسی هوش مصنوعی امن‌تر استفاده کنیم؟

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

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

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

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

آیا این آسیب‌پذیری وصله شده است؟
آنتروپیک این گزارش را در دسته‌ی «اطلاع‌رسانی» طبقه‌بندی کرده، نه یک باگ بحرانی نیازمند وصله‌ی فوری؛ و رفتار مشاهده‌شده را «طبق طراحی» توصیف کرده است. به همین دلیل، مسئولیت کاهش ریسک عملاً روی دوش کاربران و تیم‌های فنی قرار می‌گیرد.

آیا فقط کاربران Claude Code در معرض خطرند؟
خیر. گزارش‌های مستقل دیگری نشان داده‌اند که ابزارهای مشابه مانند Gemini CLI گوگل و Codex شرکت OpenAI نیز در ماه‌های اخیر با آسیب‌پذیری‌های مشابهی در مواجهه با محتوای ناشناس یا جریان‌های کاری چندمرحله‌ای روبه‌رو بوده‌اند.

ساده‌ترین راه محافظت از خودم چیست؟
اجرای عامل‌های کدنویسی درون یک محیط ایزوله (کانتینر یا ماشین مجازی)، محدودکردن دسترسی شبکه و دورنگه‌داشتن کلیدهای حساس از دسترس مستقیم عامل، سه اقدام ساده اما مؤثر هستند که در این گزارش هم بارها تکرار شده‌اند.