پژوهشگران شرکت Air Security روز ۱۷ سپتامبر ۲۰۲۶ از ضعفی به نام Plugin4Shell پرده برداشتند که به شیوهٔ نصب افزونه در چهار دستیار برنامهنویسی مربوط میشود: Claude Code، Codex، GitHub Copilot و Gemini CLI. مسئله این نیست که مدل زبانی فریب یک دستور مخرب را میخورد. اشکال در مرحلهای است که برنامه باید مطمئن شود کد دریافتشده از مخزن Git همان نسخهای است که پیشتر بررسی و تأیید شده است. به گفتهٔ پژوهشگران، در شرایط مشخصی میتوان کد دیگری را به جای نسخهٔ تأییدشده نصب کرد، بیآنکه شناسهٔ ثبتشده در بازار افزونه تغییر کند.
این خطر برای همهٔ کاربران و همهٔ مخزنها یکسان نیست. بهرهبرداری به کنترل مخزن افزونه، شیوهٔ میزبانی آن و نسخهٔ برنامهٔ نصبکننده بستگی دارد. منبعی که در این گزارش بررسی کردیم، شواهد مستقلی از یک کارزار واقعی سوءاستفاده یا شمار قربانیان این آسیبپذیری ارائه نمیکند. Aipolix نیز آزمایش نفوذ مستقلی انجام نداده است. آنچه میتوان بررسی کرد، سازوکار ضعف، مدارک اصلاح آن و اقدامهایی است که یک تیم توسعه باید برای اطمینان از افزونههای نصبشده انجام دهد.
قفلکردن نسخه کافی نیست؛ باید نتیجهٔ نصب را هم بررسی کرد
بازار افزونه معمولاً پس از بازبینی کد، شناسهٔ یک نسخهٔ مشخص از مخزن را ثبت میکند. این شناسه، هشِ یک commit است و قرار است تضمین کند هنگام نصب همان کد دریافت شود. دستیار برنامهنویسی مخزن را میگیرد و از Git میخواهد آن نسخه را انتخاب کند. پژوهشگران Air دریافتند که برنامههای آسیبپذیر موفقبودن فرمان را به معنای نصب نسخهٔ درست میگرفتند، بیآنکه شناسهٔ واقعی نسخهٔ انتخابشده را با مقدار ثبتشده مقایسه کنند.
در Claude Code، Codex و Copilot راه سوءاستفاده به یک ابهام در تشخیص نام شاخه و شناسهٔ نسخه مربوط میشود. اگر کسی کنترل مخزن افزونه را به دست آورده باشد، میزبان اجازهٔ انتخاب نامی شبیه هش کامل را بدهد و آن شاخه، شاخهٔ پیشفرض مخزن باشد، Git ممکن است نام را به جای نسخهٔ مورد انتظار تفسیر کند. در نتیجه فایلهای دیگری نصب میشوند. این روش بدون کنترل مخزن قابل اجرا نیست و روی همهٔ سرویسهای میزبانی Git نیز جواب نمیدهد.
GitHub میگوید اجازه نمیدهد شاخه یا برچسبی با نام شبیه هش نسخه ساخته شود؛ بنابراین روش یادشده در مخزنهایی که روی خود GitHub میزبانی میشوند کار نمیکند. اما افزونه میتواند از مخزنهای دیگری مانند Bitbucket یا سرور Git سازمان دریافت شود. از اینکه فهرست افزونهها در یک بازار معتبر قرار دارد، نمیتوان نتیجه گرفت که تمام مخزنهای پشت آن نیز از همین محدودیت برخوردارند.
پژوهشگران برای Gemini CLI شیوهٔ متفاوتی را شرح دادهاند. برنامه ابتدا نسخهٔ موردنظر را دریافت میکند، اما هنگام انتخاب نهایی به نام FETCH_HEAD رجوع میکند؛ اگر این نام با شاخهای در مخزن تداخل پیدا کند، ممکن است کد دیگری انتخاب شود. پس جلوگیری از ساخت شاخههای شبیه هش، بهتنهایی راهحل مشترک همهٔ محصولات نیست. بررسی شناسهٔ واقعی نسخهٔ نصبشده، نقطهٔ مشترک هر دو مسئله است.
چرا بهروزرسانی خودکار خطر را بیشتر میکند؟
در سناریوی تشریحشده، نویسندهٔ افزونه ابتدا کدی سالم ارائه میکند و تأیید بازار را میگیرد. حتی بهروزرسانی بعدی نیز ممکن است هنگام بررسی سالم باشد. پس از ثبت شناسهٔ تازه، گردانندهٔ مخرب مخزن کاری میکند که فرایند نصب به کد دیگری برسد. اگر دستیار افزونههای نصبشده را خودکار بهروزرسانی کند، کاربر لازم نیست بار دیگر روی دکمهٔ نصب کلیک کند. Air میگوید این رفتار در تنظیمات پیشفرض Claude Code و Codex وجود دارد؛ نباید آن را بدون بررسی به همهٔ نصبها تعمیم داد.
افزونهٔ آلوده ممکن است به فایلهای پروژه یا اعتبارنامههایی دسترسی پیدا کند که در اختیار فرایند دستیار قرار دارند. به همین دلیل پژوهشگران از امکان اجرای کد از راه دور صحبت میکنند. این اصطلاح به پیامد احتمالی حملهٔ موفق اشاره دارد، نه اینکه همهٔ کاربران این چهار محصول هدف حمله قرار گرفتهاند. تأیید اولیهٔ بازار، سالم بودن نسخهٔ قبلی و نمایش یک شناسهٔ ثابت، هیچکدام بهتنهایی ثابت نمیکنند چه کدی روی دستگاه اجرا شده است.
نکتهٔ اصلی برای تیم امنیت این است که سه پرسش را جدا بررسی کند: بازار چه نسخهای را تأیید کرده، برنامه واقعاً چه نسخهای را دریافت کرده و کد نصبشده چه اختیاراتی دارد؟ پاسخ پرسش اول را بازار میدهد، محدودیت نامگذاری شاخه به میزبان مربوط است و پاسخ پرسش دوم باید هنگام نصب روشن شود. مجوزهای اجرا هم تعیین میکنند که خطای نصب تا کجا میتواند خسارت ایجاد کند.
اصلاحیهها چه وضعیتی دارند؟
Air میگوید Anthropic این ضعف را در Claude Code نسخهٔ 2.1.179 برطرف کرده و در ۱۷ ژوئن به پژوهشگران اطلاع داده است. توضیحات عمومی همان نسخه، نام این آسیبپذیری را مستقلاً ذکر نمیکند؛ بنابراین انتساب اصلاحیه به این نسخه بر اساس گزارش پژوهشگران است. دربارهٔ Codex مدرک مستقیمتری وجود دارد: تغییر ادغامشده در مخزن رسمی OpenAI میگوید برنامه پس از دریافت افزونه، شناسهٔ واقعی HEAD را با هش درخواستی مقایسه میکند و در صورت مغایرت نصب را رد خواهد کرد. همین تغییر در فهرست نسخهٔ 0.146.0 نیز آمده است.
دربارهٔ Copilot، پژوهشگران در روز انتشار گزارش گفتهاند اصلاحیهای از سوی مایکروسافت دریافت نکردهاند. در تاریخ بررسی این مقاله نیز از فهرست عمومی نسخههای Copilot CLI نمیتوان اصلاحیهٔ مشخصی برای Plugin4Shell را تأیید کرد. این به معنای اطلاع قطعی از تمام اقدامهای داخلی شرکت نیست. GitHub در پاسخ به رسانهٔ The Register بر محدودیت نامگذاری شاخه در سرویس خود تأکید کرده؛ پژوهشگران یادآور شدهاند که مخزن افزونه میتواند روی سرویس دیگری باشد.
وضعیت Gemini CLI نیازمند دقت بیشتری است. Air گزارش داده که گوگل گفته این ضعف را اصلاح نمیکند و مهاجرت به Antigravity را پیشنهاد داده است. بااینحال، مستندات رسمی Gemini CLI نسخهٔ پایدار 0.60.0 را با تاریخ ۱۵ سپتامبر و چند بهبود امنیتی دیگر ثبت کردهاند. پس نمیتوان از گزارش مربوط به این ضعف نتیجه گرفت توسعهٔ کل برنامه کاملاً متوقف شده یا آن بهبودهای دیگر حتماً Plugin4Shell را برطرف کردهاند. کاربرانی که هنوز از آن استفاده میکنند باید پاسخ مشخص گوگل دربارهٔ همین مشکل را ملاک قرار دهند.
برای بررسی افزونههای نصبشده از کجا شروع کنیم؟
نخست نسخهٔ دقیق هر دستیار، فهرست افزونهها، نشانی مخزن آنها و میزبان Git را ثبت کنید. سپس شناسهٔ نسخهای را که بازار تأیید کرده با شناسهٔ واقعی نسخهٔ موجود در پوشهٔ نصب مقایسه کنید. صرفاً به پیام موفقیت نصب اعتماد نکنید. اگر اختلافی پیدا شد، پیش از اجرای دوبارهٔ افزونه شواهد را حفظ و موضوع را بررسی کنید. تنظیمات بهروزرسانی خودکار و دسترسی افزونه به فایلها، شبکه و اعتبارنامهها نیز باید در همین ارزیابی دیده شود.
برای Claude Code و Codex نسخههای دارای اصلاحیه را نصب کنید. اگر اصلاحیهٔ تأییدشدهای برای محصولی در دسترس نیست، محدودکردن مخزنهای غیرقابلاعتماد و بهروزرسانیهای خودکار میتواند احتمال برخورد با حمله را کاهش دهد؛ اما جای اصلاح مشکل در برنامه را نمیگیرد. همچنین نصب نسخهٔ جدید ثابت نمیکند افزونهٔ آلودهای که پیشتر اجرا شده، پاک شده یا اطلاعاتی افشا نشده است. مدارک موجود چنین پاکسازی خودکاری را تأیید نمیکنند و در صورت مشاهدهٔ اجرای افزونهٔ مشکوک باید دامنهٔ دسترسی و اعتبارنامههای احتمالیِ در معرض خطر جداگانه بررسی شود.
درس Plugin4Shell فقط یک هشدار دربارهٔ افزونههای هوش مصنوعی نیست: ثبت شناسهٔ نسخه، تأیید اینکه همان نسخه نصب شده و محدودکردن اختیارات کد، سه کنترل مستقلاند. تا وقتی هر سه در عمل بررسی نشوند، عبارت «افزونهٔ تأییدشده» بهتنهایی پاسخ مناسبی برای ارزیابی خطر نیست.