دستیارهای کدنویسی هوش مصنوعی مانند Claude Code، Cursor و Grok Build می‌توانند بلافاصله پس از اینکه توسعه‌دهنده یک مخزن (repository) غیرقابل اعتماد را باز می‌کند، بدون هیچ کلیک یا تأییدی، دستورات دلخواه را اجرا کنند. این نقص از روشی ناشی می‌شود که این ابزارها برای اسکن فایل‌های یک پروژه، از ویژگی core.fsmonitor در Git استفاده می‌کنند.

چرا این موضوع اکنون اهمیت دارد

توسعه‌دهندگان به‌طور فزاینده‌ای به عامل‌های هوش مصنوعی (AI agents) برای پیشنهاد کد، بازنویسی توابع (refactor) یا حتی نوشتن ماژول‌های کامل تکیه می‌کنند. این عامل‌ها برای داشتن یک تصویر لحظه‌ای (snapshot) سریع از فضای کاری، دستور git status را در پس‌زمینه اجرا می‌کنند. وقتی Git فایل .git/config یک مخزن را می‌خواند، هر مقداری که به core.fsmonitor اختصاص داده شده باشد، به عنوان یک دستور شل (shell command) در نظر گرفته می‌شود که Git آن را اجرا خواهد کرد. یک مهاجم می‌تواند دستوری مخرب را در آن ورودی تنظیمات قرار دهد و فراخوانی پس‌زمینه Git توسط هوش مصنوعی، پیش از آنکه کاربر حتی یک خط کد تایپ کند، آن دستور را اجرا می‌کند.

این کد با همان سطح دسترسی توسعه‌دهنده اجرا می‌شود و محیط ایزوله‌ای (sandbox) را که عامل هوش مصنوعی معمولاً در آن فعالیت می‌کند، دور می‌زند. در عمل، یک مخزن آلوده می‌تواند بدافزار نصب کند، اعتبارنامه‌ها را سرقت کند یا فایل‌های منبع را تغییر دهد، در حالی که توسعه‌دهنده تصور می‌کند دستیار هوش مصنوعی صرفاً در حال ارائه پیشنهاد است.

حمله چگونه رخ می‌دهد

  1. آماده‌سازی – مهاجم مخزنی ایجاد می‌کند که در .git/config آن خطی مانند core.fsmonitor = /path/to/malicious/script وجود دارد.
  2. تحویل – مخزن به صورت یک فایل zip، از طریق فلش مموری، همگام‌سازی شده در یک درایو مشترک یا به هر روش دیگری که پوشه .git از قبل در آن موجود باشد، به سیستم قربانی منتقل می‌شود.
  3. تحریک (Trigger) – توسعه‌دهنده پوشه را در یک IDE مجهز به هوش مصنوعی باز می‌کند. دستیار برای جمع‌آوری اطلاعات زمینه (context)، دستور git status را اجرا می‌کند. Git تنظیمات محلی را می‌خواند، دستور core.fsmonitor را اجرا می‌کند و اسکریپت مخرب بلافاصله اجرا می‌شود.

یک دستور ساده git clone این ریسک را ایجاد نمی‌کند، زیرا کلون کردن یک دایرکتوری .git تازه ایجاد می‌کند که فاقد تنظیمات دستکاری‌شده است. این حمله تنها زمانی کار می‌کند که مهاجم بتواند یک پوشه .git از پیش موجود را ارائه دهد.

آنچه در خطر است

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

از آنجایی که دستور مخرب از حقوق کاربر ارث‌بری می‌کند، می‌تواند هر فایلی را که توسعه‌دهنده اجازه دارد تغییر دهد، از جمله کلیدهای SSH، اسکریپت‌های ساخت (build scripts) یا اعتبارنامه‌های استقرار (deployment credentials) را اصلاح کند.

گام‌های کاهش ریسک که توسعه‌دهندگان می‌توانند از امروز انجام دهند

  • به تنظیمات محلی Git اعتماد نکنید. تنظیمات یک مخزن هر بار که یک دستیار هوش مصنوعی از پروژه پرس‌وجو می‌کند، مقادیر جهانی (global) را بازنویسی می‌کند.

  • ورودی core.fsmonitor را بررسی کنید قبل از باز کردن یک پوشه با استفاده از دستیار: 

    git config --get core.fsmonitor

    اگر هر مقداری مشاهده شد، آن را مشکوک تلقی کنید.

  • ورودی را حذف کنید با استفاده از: 

    git config --local --unset core.fsmonitor

  • سایر کلیدهای پرخطر را بررسی کنید که Git می‌تواند آن‌ها را اجرا کند: hooksPath ،sshCommand ،pager ،editor ،filter. از همان الگوی git config --get برای تأیید خالی بودن آن‌ها استفاده کنید.

  • استفاده از کلون‌های تمیز (clean clones) برای هر کدی که قصد دارید به یک ابزار هوش مصنوعی بدهید. اگر مجبور هستید با یک فایل zip یا پوشه منتقل شده کار کنید، دایرکتوری .git آن را حذف کرده و مخزن را دوباره مقداردهی اولیه (re-initialize) کنید، یا ابتدا بررسی‌های بالا را انجام دهید.

مسئولیت بر عهده کیست

این آسیب‌پذیری نقص در مدل‌های زبانی نیست که قدرت Claude Code، Cursor یا Grok Build را تأمین می‌کنند؛ بلکه نتیجه روشی است که این ابزارها اطلاعات فایل‌ها را جمع‌آوری می‌کنند. برخی از فروشندگان شروع به ایزوله‌سازی (sandboxing) دقیق‌تر فراخوانی‌های Git کرده‌اند، اما رفتار پیش‌فرض همچنان به تنظیمات مخزن محلی اعتماد می‌کند. تا زمانی که صنعت استانداردی را اتخاذ کند که ورودی‌های تنظیمات بالقوه خطرناک را هنگام اسکن فضای کاری توسط عامل هوش مصنوعی حذف یا نادیده بگیرد، توسعه‌دهندگان باید آخرین خط دفاعی باقی بمانند.

در آینده باید منتظر چه چیزهایی باشیم

  • به‌روزرسانی‌های ابزار که قبل از فراخوانی git status تنظیمات Git را به‌طور صریح پاکسازی (sanitize) می‌کنند.
  • دستورالعمل‌های جامعه‌محور برای توسعه امن با کمک هوش مصنوعی، که احتمالاً شامل بررسی‌های پیش‌نیاز (pre-flight checks) توصیه‌شده خواهد بود.
  • تحقیقات امنیتی که ممکن است کلیدهای تنظیمات Git دیگری را کشف کنند که قادر به اجرای کد هستند و فهرست بررسی را فراتر از پنج مورد ذکر شده در بالا گسترش دهند.

خلاصه کلام: یک دستیار هوش مصنوعی می‌تواند یک برنامه‌نویس همراه (pair-programmer) راحت باشد، اما با کمال میل هر دستوری را که در تنظیمات Git یک مخزن پنهان شده باشد، اجرا خواهد کرد. قبل از اینکه اجازه دهید دستیار به فضای کاری شما دسترسی داشته باشد، آن را بررسی کنید.