پرش به محتوای اصلی
پرش به محتوای مقاله

چطور Plugin4Shell مکانیزم‌های امنیتی Claude Code و Gemini را دور می‌زند؟

·۲۷ شهریور ۱۴۰۵۸ دقیقه مطالعه۱ بازدید
آسیب‌پذیری اجرای کد از راه دور بدون کلیک در ۴ ابزار کدنویسی محبوب، میلیون‌ها کاربر در معرض خطر
آسیب‌پذیری اجرای کد از راه دور بدون کلیک در ۴ ابزار کدنویسی محبوب، میلیون‌ها کاربر در معرض خطر
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

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

تصور کنید ابزاری که برای افزایش سرعت کدنویسی شما نصب کرده‌اید، ناگهان به درِ پشتی برای نفوذ به تمام اسرار تجاری شرکت شما تبدیل شود. این کابوس اکنون برای میلیون‌ها کاربر Claude Code، GitHub Copilot و Gemini CLI به واقعیت تبدیل شده است.

به گزارش Air Security در ۱۷ سپتامبر ۲۰۲۶، آسیب‌پذیری موسوم به Plugin4Shell به مهاجمان اجازه می‌دهد کنترل کامل ماشین کاربر را به دست بگیرند. این حمله از طریق دور زدن دقیقاً همان مکانیسم امنیتی که برای متوقف کردن آن‌ها طراحی شده بود، رخ می‌دهد. این اکسپلویت از یک نقص طراحی واحد در نحوه مدیریت به‌روزرسانی‌های افزونه توسط عامل‌های هوش مصنوعی نشأت می‌گیرد و دری را برای اجرای کد از راه دور (RCE) به‌صورت «بدون کلیک» (Zero-Click) در محبوب‌ترین ابزارهای کدنویسی صنعت باز می‌کند.

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

از آنجایی که این عامل‌ها معمولاً با تمام قابلیت‌های کارمندی که آن‌ها را اجرا می‌کند فعالیت می‌کنند، دسترسی یکسانی به داده‌های حساس و محیط‌های عملیاتی دارند. افزونه‌ها به‌طور پیش‌فرض این مجوزها را به ارث می‌برند. بنابراین، اگر یک افزونه آلوده شود، مهاجم نیازی به ارتقای سطح دسترسی (Privilege Escalation) ندارد؛ آن‌ها مستقیماً به اجرای کد از راه دور روی ماشین کارمند دست می‌یابند و همان دسترسی‌هایی را به «جواهرات تاج» یا حیاتی‌ترین دارایی‌های سازمان پیدا می‌کنند که آن کارمند داشته است.

روایت وقایع تا امروز

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

  • داستان مهارت‌ها (The Story of Skills): محققان Air Security یک مهارت مخرب ساختند و شاهد ویروسی شدن آن بودند که منجر به تصاحب کنترل بیش از ۲۶,۰۰۰ عامل شد. این موضوع ثابت کرد که قرار دادن کد در یک بازار مورد اعتماد، بخش سخت کار نیست.
  • ربایش مهارت (SkillJacking): محققان نشان دادند که مهاجمان حتی نیازی به کاشتن کد جدید ندارند. آن‌ها با تصاحب مخازنی (Repositories) که پشت مهارت‌های موجود بودند، ۹۲۵ مهارت در حال استفاده را ربودند که ۱۳۴,۰۰۰ عامل را تحت تأثیر قرار داد.

برای مقابله با این حملات موسوم به «rug-pull» (کلاهبرداری با تغییر ناگهانی کد)، صنعت مدل SHA pinning را پذیرفت. در این مدل امنیتی، کد در یک کامیت (Commit) خاص بررسی می‌شود، آن کامیت پین (ثبیت) می‌شود و اعتماد بر این است که همان کامیت پین‌شده برای همیشه اجرا خواهد شد. اما Plugin4Shell داستان شکست همین مرز امنیتی است.

چرا Plugin4Shell منحصر‌به‌فرد است؟

این آسیب‌پذیری نشان‌دهنده یک تغییر بنیادین در چشم‌انداز تهدیدات هوش مصنوعی است. این اولین آسیب‌پذیری زنجیره تأمین (Supply Chain) در اکوسیستم عامل‌های هوش مصنوعی است. در حالی که کارهای امنیتی قبلی مدل یا خودِ عامل را هدف قرار می‌دادند، Plugin4Shell لایه توزیع زیرین آن‌ها را هدف می‌گیرد؛ یعنی بازارهایی که از طریق آن‌ها افزونه‌های عامل به میلیون‌ها ماشین می‌رسند.

این آسیب‌پذیری با سه عامل حیاتی شناخته می‌شود:

  • RCE بدون کلیک (Zero-Click): هیچ تعاملی از سوی کاربر لازم نیست. نتیجه، تسخیر کامل عامل و میزبان (Host) است که روی آن اجرا می‌شود و دسترسی کامل به هر دارایی و داده‌ای که عامل به آن دسترسی دارد فراهم می‌کند.
  • خطای طراحی در سطح صنعت: این یک لغزش در پیاده‌سازی یک محصول خاص نبود. همین خطای طراحی در هر عامل متأثر وجود دارد و نشان‌دهنده یک اشتباه واحد است که در سراسر صنعت تکرار شده است.
  • ناتوانی بازارها (Marketplace Impotence): یک بازار نمی‌تواند این حفره را به‌طور کامل ببندد زیرا پین (Pin) در داخل خودِ عامل حل (Resolve) می‌شود. اگرچه یک بازار می‌تواند با پذیرش تنها میزبان‌هایی که نام‌های شبیه به SHA را رد می‌کنند، اثر حمله «نام شاخه» را کاهش دهد (که عملاً محدود به GitHub می‌شود)، اما این کار باعث حذف میزبان‌هایی می‌شود که عامل‌ها رسماً پشتیبانی می‌کنند و هیچ تأثیری روی نسخه Gemini CLI نخواهد داشت.

مکانیسم دور زدن (Bypass)

Plugin4Shell ثابت می‌کند که SHA pinning در اکوسیستم فعلی عامل‌ها یک توهم است. این یک دور زدن پینینگ SHA افزونه است: عامل دقیقاً کامیتی را که بازار پین کرده است دریافت (Checkout) می‌کند، اما هرگز تأیید نمی‌کند که واقعاً در آن نقطه فرود آمده است. این به مهاجمی که کنترل مخزن افزونه را دارد اجازه می‌دهد تا عملیات checkout را به کد مخرب هدایت کند، در حالی که پین هنوز مورد احترام به نظر می‌رسد.

طبق گزارش Air Security، این حمله بسته به نوع عامل، به دو روش اصلی ظاهر می‌شود:

حمله شاخه-به-هش (Branch-as-Hash)

(در Claude Code، OpenAI Codex و GitHub Copilot)

این عامل‌ها مخزن را کلون کرده و دستور git checkout <pinned-sha> را اجرا می‌کنند. مهاجم شاخه‌ای می‌سازد که نام آن دقیقاً همان SHA پین‌شده ۴۰ کاراکتری (hex) است و آن را به عنوان شاخه پیش‌فرض مخزن قرار می‌دهد.

  • منطق گیت (Git Logic): چون گیت در صورت تداخل نام‌ها، یک مرجع (Reference/Branch) را بر یک شناسه شیء (Object ID/Commit) ترجیح می‌دهد، SHA پین‌شده را به شاخه مخرب حل می‌کند. گیت تنها یک هشدار «refname is ambiguous» چاپ می‌کند که عامل آن را نادیده می‌گیرد.
  • پیش‌نیازها: دو شرط برای موفقیت این حمله لازم است: اول اینکه چیزی مانع نام‌گذاری شاخه شبیه به هش نشود (که خودِ دستور git check-ref-format نام‌های ۴۰ کاراکتری hex را می‌پذیرد)، و دوم اینکه شاخه باید پیش‌فرض مخزن باشد. یک شاخه غیرپیش‌فرض فقط به عنوان یک ref ردیابی‌کننده راه دور دریافت می‌شود و در آن صورت checkout به کامیت بازمی‌گردد.
  • سازگاری میزبان: این روش روی میزبان‌هایی مانند Bitbucket و سرورهای گیت شخصی (Self-hosted) که نام‌های شاخه ۴۰ کاراکتری را می‌پذیرند کار می‌کند، هرچند GitHub آن‌ها را رد می‌کند. نکته قابل توجه این است که مستندات خودِ Anthropic، میزبان‌های Bitbucket و گیت‌های شخصی را به عنوان بک‌اندهای معتبر بازار لیست کرده است.

حمله FETCH_HEAD

(در Gemini CLI)

ابزار Gemini با استفاده از --ref پین می‌کند و نصب را در سه مرحله انجام می‌دهد: git clone --depth 1 <plugin repo>، سپس git fetch origin <sha> و در نهایت git checkout FETCH_HEAD.

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

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

چرا این حمله «بدون کلیک» است؟

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

یک مهاجم می‌تواند از دو مسیر اصلی این موضوع را استثمار کند:

۱. انتشار و چرخش (Publish and Pivot): مهاجم یک افزونه واقعاً بی‌خطر را در یک بازار مورد اعتماد منتشر می‌کند، از بررسی‌های امنیتی عبور می‌کند و سپس محتوای آن را با نسخه‌ای مخرب جایگزین می‌کند. Air Security پیش از این در «داستان مهارت‌ها» ثابت کرده است که این کار ممکن است.
۲. ربایش مخزن (Repository Hijacking): مهاجم کنترل مخزن پشت یک افزونه قانونی را که بازار از قبل به آن اعتماد کرده به دست می‌گیرد، سپس از Plugin4Shell استفاده می‌کند تا نسخه مخرب را به هر عاملی که آن را نصب کرده تحمیل کند. این کار پینینگ نسخه‌ای را که دقیقاً برای جلوگیری از چنین تصاحب‌هایی وجود دارد، دور می‌زند؛ زنجیره‌ای که از ابتدا تا انتها از طریق SkillJacking و RepoJacking اثبات شده است.

زنجیره کامل حمله به این ترتیب پیش می‌رود:

  • کاشت (Plant): مهاجم یک افزونه بی‌خطر را منتشر می‌کند که روی کامیت aaa...aaa پین شده است. این افزونه تأیید می‌شود.
  • پذیرش (Adoption): کاربران آن را نصب می‌کنند. هر نصب به نسخه تأییدشده و مورد اعتماد aaa...aaa پین می‌شود.
  • ارتقای نسخه (Version Bump): مهاجم یک به‌روزرسانی روتین ارائه می‌دهد؛ بازار دوباره روی یک کامیت جدید و همچنان بی‌خطر bbb...bbb پین می‌کند.
  • کلاهبرداری (Rug-pull): مهاجم شاخه‌ای به نام bbb...bbb می‌سازد، آن را به عنوان پیش‌فرض مخزن قرار می‌دهد و آن را به کد مخرب متصل می‌کند. خودِ کامیت پین‌شده می‌تواند دست‌نخورده باقی بماند.
  • به‌روزرسانی خودکار به RCE: تغییر پین، به‌روزرسانی خودکار پس‌زمینه را در هر عامل فعال می‌کند. عملیات checkout مقدار bbb...bbb را به شاخه حل می‌کند و کد بدون هیچ پیامی اجرا می‌شود.

پاسخ سازندگان و کاهش مخاطرات

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

وضعیت وصله‌ها (Patches) تا سپتامبر ۲۰۲۶ پراکنده است:

  • Anthropic پس از افشای نقص، Claude Code را در نسخه ۲.۱.۱۷۹ اصلاح کرد.
  • OpenAI این نقص را در نسخه ۰.۱۴۶.۰ Codex برطرف کرد.
  • Microsoft از نقص در GitHub Copilot مطلع شده است، اما هنوز اصلاحیه‌ای ارائه نکرده و کاربران را در معرض خطر قرار داده است.
  • Google ابزار Gemini CLI را بازنشسته (Deprecated) کرده و آن را وصله نخواهد کرد. به کاربران توصیه شده به Antigravity مهاجرت کنند که آسیب‌پذیر نیست زیرا هیچ سیستم پینینگ SHA برای افزونه‌های بازار ندارد که بتوان آن را دور زد.

شکست سیستماتیک

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

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

برای رفع واقعی این مشکل، عامل‌ها باید یک تأییدیه (Assertion) پس از checkout پیاده‌سازی کنند تا تأیید شود HEAD حل‌شده با SHA پین‌شده مطابقت دارد:
test "$(git rev-parse HEAD)" = "<pinned-sha>" || abort

بسیار حیاتی است که HEAD حل‌شده بررسی شود، نه مرجعی (Ref) که درخواست شده بود؛ این تمایز دقیقاً همان چیزی است که نسخه Gemini از آن عبور می‌کند.

جدول زمانی وقایع

  • می ۲۰۲۶: توسط آزمایشگاه تحقیقات Air Security با یک PoC فعال علیه هر چهار عامل کشف شد.
  • ژوئن ۲۰۲۶: تحت افشای هماهنگ به هر چهار سازنده گزارش شد.
  • ۱۷ ژوئن ۲۰۲۶: Anthropic اصلاحیه در Claude Code 2.1.179 را تأیید کرد.
  • ۴ اوت ۲۰۲۶: گوگل تأیید کرد که به دلیل بازنشستگی، هیچ اصلاحیه‌ای برای Gemini CLI ارائه نمی‌شود و کاربران را به Antigravity ارجاع داد.
  • ۱۲ اوت ۲۰۲۶: اصلاحیه Codex 0.146.0 تأیید شد.

سازمان‌هایی که از Air Marketplace و Air Filter استفاده می‌کردند، تحت تأثیر Plugin4Shell قرار نگرفتند. برای یادگیری بیشتر درباره نحوه محافظت Air در برابر آسیب‌پذیری‌های زنجیره تأمین عامل‌ها، دمو رزرو کنید.

گام بعدی شما

  • اگر از GitHub Copilot یا نسخه‌های قدیمی Claude Code استفاده می‌کنید، فوراً به آخرین نسخه به‌روزرسانی کنید.
  • دسترسی‌های عامل‌های هوش مصنوعی در سیستم‌های عملیاتی (Production) را به حداقل ممکن (Least Privilege) برسانید.
  • از نصب افزونه‌های متفرقه از بازارهای عمومی در محیط‌های حساس سازمانی خودداری کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.

چرا این موضوع مهم است؟

این نقص اعتبار مکانیزم SHA-pinning را به عنوان استاندارد امنیتی در عامل‌های AI از بین برد. بر اساس تجربه محققان Air Security، این موضوع ثابت می‌کند که حتی سخت‌گیرانه‌ترین فرآیندهای بازبینی کد نیز در برابر نقص‌های لایه توزیع ناتوان هستند.

تأثیر برای ایران

به‌دلیل محدودیت‌های دسترسی به APIهای رسمی و استفاده گسترده از نسخه‌های غیررسمی یا واسط در ایران، احتمال قرار گرفتن در معرض نسخه‌های اصلاح‌نشده این ابزارها برای توسعه‌دهندگان ایرانی بیشتر است.

·نگاه ما
تحریریه دات‌هوش

این حمله نشان می‌دهد که نقطه ضعف فعلی اکوسیستم عامل‌ها، نه در استدلال مدل، بلکه در لایه توزیع و مدیریت بسته است. اعتماد به ابزارهای استاندارد مانند Git برای تأمین امنیت در سطح اپلیکیشن، یک اشتباه استراتژیک است؛ زیرا ابزارهای زیرساختی برای کارایی طراحی شده‌اند، نه برای مقابله با حملات زنجیره تأمین هوشمند. در واقع، ما شاهد انتقال حملات از «تزریق پرامپت» به «تزریق زیرساخت» هستیم.

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.