تزریق پرامپت؛ تهدید شماره یک امنیت عامل‌های کدنویسی در سال ۲۰۲۶

یک جملهٔ ساده و مخفی در فایل README یک مخزن عمومی گیت‌هاب، اکنون می‌تواند کنترل کامل ترمینال شما را به یک مهاجم بدهد. این واقعیتِ تلخِ تزریق پرامپت (Prompt Injection) است؛ تهدیدی که OWASP آن را با کد LLM01، به عنوان بالاترین ریسک امنیتی برای برنامه‌های مبتنی بر مدل زبانی بزرگ (LLM) در سال ۲۰۲۶ معرفی کرده است. این حمله نیازی به رمز عبور سرقتی یا باگ‌های نرم‌افزاری سنتی ندارد. تنها کافی است جمله‌ای در جایی قرار بگیرد که یک عامل (Agent) — شبیه به دستیاری که دستورات شما را اجرا می‌کند اما تفاوت بین دستور رئیس و یادداشت‌های حاشیه‌ای را نمی‌فهمد — آن را بخواند و نتواند دستور مخفی را از دستورات واقعی شما تشخیص دهد.

تصور کنید دستیار هوش مصنوعی شما در حال خلاصه‌سازی یک سند است. در میانهٔ متن، جمله‌ای مخفی به او دستور می‌دهد که کار را رها کند و کلیدهای خصوصی API شما را فاش کند. در این لحظه، سند عملاً جایگزین کاربر شده و هدف سیستم را تغییر می‌دهد. این فروپاشیِ مرز اعتماد، دلیل آن است که پژوهشگران امنیتی تزریق پرامپت را با حملات کلاسیک SQL Injection در وب‌های اولیه مقایسه می‌کنند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مشکل بنیادین در ناتوانی مدل در تفکیک «داده» از «دستور» است؛ درست مانند یک پایگاه داده که نمی‌تواند تفاوت بین یک پرس‌وجوی (Query) واقعی و داده‌ای را که درون آن پرس‌وجو جاسازی شده تشخیص دهد، مدل‌های هوش مصنوعی نیز دستورات و محتوا را از طریق یک کانال واحد می‌خوانند.

در حالی که یک چت‌بات معمولی ممکن است در صورت تزریق پرامپت، تنها متنی خجالت‌آور یا نامناسب تولید کند، عامل‌های کدنویسی دایرهٔ تخریب بسیار وسیع‌تری دارند. این ابزارها معمولاً دسترسی‌های دائمی و گسترده‌ای برای دسترسی به سیستم فایل شما، اجرای دستورات شل (Shell)، مدیریت اعتبارنامه‌های گیت و دسترسی به کلیدهای API دارند. اگر مدل نتواند بین دستورات صریح شما و محتوایی که در حال خواندن آن است تمایز قائل شود، دستور مخفی مهاجم به اولویت اول سیستم تبدیل می‌شود.

هدف: ابزارهای کدنویسی عامل‌محور

به نقل از گزارش ۲۰۲۶ سازمان OWASP's State of AI Surveyor، عامل‌های کدنویسی به هدف اصلی این حملات تبدیل شده‌اند. این نظرسنجی ۵۳ پروژهٔ هوش مصنوعی عامل‌محور را بررسی کرد و دریافت که ۲۸ مورد از آن‌ها — یعنی بیش از نیمی از کل مجموعه داده‌ها — عامل‌های کدنویسی بودند. اگرچه این ابزارها در صدر لیست ریسک‌ها هستند، اما داده‌های OWASP نشان می‌دهد که تزریق پرامپت در رتبه‌ی ۱۲ام حوادث امنیتی واقعی هوش مصنوعی قرار دارد، که تفاوت میان ریسک تئوریک و وقوع عملی را نشان می‌دهد.

پنج ابزار با سریع‌ترین رشد در کل این مجموعه داده، همگی در این دسته قرار داشتند:

• Claude Code
• Gemini CLI
• Codex
• Cline
• Aider

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

آسیب‌پذیری‌های بحرانی تأییدشده

این ریسک‌ها تئوریک نیستند. طبق گزارش‌های منتشر شده، بین سال‌های ۲۰۲۵ و ۲۰۲۶، آسیب‌پذیری‌های بحرانی با امتیاز CVSS بالای ۹.۰ در GitHub Copilot، Microsoft Copilot و Cursor تأیید شده است.

• Cursor: در سال ۲۰۲۶، زنجیره‌ای از سه CVE متمایز نشان داد که مهاجمان چگونه می‌توانند محیط اجرای یک عامل را مسموم کنند. این زنجیره شامل یک دور زدن دستورات داخلی شل (CVE-2026-22708 با امتیاز ۹.۸) و یک فرار از گیت‌هوک (CVE-2026-26268) بود که اجازه می‌داد محموله‌های مخرب حتی از طریق دستوراتی که در لیست سفید (Allowlist) بودند، اجرا شوند.
• GitHub Copilot: پژوهشگران یک نقص اجرای کد از راه دور (RCE) را از طریق تزریق پرامپت در سطح پیشنهاد کد افشا کردند (CVE-2025-53773). اکسپلویت دوم به نام «CamoLeak» (امتیاز ۹.۶) از زیرساخت پروکسی تصاویر گیت‌هاب در داخل Copilot Chat سوءاستفاده می‌کرد؛ این نقص در نهایت با غیرفعال کردن کامل رندر تصاویر برطرف شد.
• Microsoft 365 Copilot: آسیب‌پذیری «EchoLeak» (CVE-2025-32711 با امتیاز ۹.۳) این دستیار بهره‌وری عمومی را هدف قرار داد. این نخستین مورد مستند از تزریق پرامپت بود که توانست بدون هیچ‌گونه تعاملی از سوی کاربر، داده‌ها را استخراج (Exfiltrate) کند. همین کلاس از حملات از آن زمان در ابزارهای تخصصی کدنویسی نیز ظاهر شده است.

مکانیسم حمله

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

وقتی توسعه‌دهنده از دستیار خود می‌خواهد آن فایل را بررسی کند، مخزن را خلاصه کند یا یک وابستگی را فراخوانی کند، مدل دستور مخفی را به‌عنوان فرمان مستقیم کاربر می‌خواند. در بدترین موارد افشا شده، عامل با همان سطح دسترسی‌هایی که توسعه‌دهنده دارد، این دستورات را اجرا می‌کند. برای مقابله با این نوع حملات غیرمستقیم، برخی شرکت‌ها راهکارهای پیشرفته‌ای را اتخاذ کرده‌اند؛ برای مثال معماری Meta Muse از یک استراتژی دفاعی خاص برای شناسایی و خنثی‌سازی تزریق‌های غیرمستقیم استفاده می‌کند.

یک پژوهش افشا شده نشان داد که مسیری برای اجرای کد از راه دور (RCE) وجود دارد که تنها به یک دستور مخرب در README یک مخزن عمومی یا یک کامنت کد نیاز دارد. از آنجایی که چندین ابزار، فایل‌های اجرایی را با استفاده از یک ترتیب جست‌وجوی پیش‌بینی‌پذیر پیدا می‌کنند، پژوهشگران ثابت کردند که این اتفاق می‌تواند قبل از نمایش هرگونه هشدار تأیید (Trust Prompt) به کاربر، منجر به اجرای باینری شود.

نرخ موفقیت و اثرات واقعی

برآوردهای صنعتی دربارهٔ موفقیت این حملات هشداردهنده است. یک عدد مورد استناد، نرخ موفقیت تزریق پرامپت در دنیای واقعی را بین ۵۰٪ تا ۸۴٪ می‌داند که بسته به پیکربندی سیستم و دفاع‌های به‌کار رفته متفاوت است.

شرکت امنیتی CrowdStrike در سال ۲۰۲۶ فعالیت‌های تزریق پرامپت علیه بیش از ۹۰ سازمان را مستند کرد. علاوه بر این، یک بنچمارک دانشگاهی با استفاده از ۳۱۴ محموله حمله مختلف که با ۷۰ تکنیک MITRE ATT&CK مطابقت داشت، دریافت که ویرایشگرهای کد را می‌توان به‌طور قابل‌اعتمادی برای اجرای دستورات غیرمجاز در ترمینال به خدمت گرفت.

اگرچه این اعداد از سازمان‌های مختلف و با متدهای متفاوت به دست آمده‌اند، اما همگی بر یک جهت اتفاق‌نظر دارند: این یک ریسک واقعی و فعال است که مورد بهره‌برداری می‌گیرد، نه یک مورد خاص تئوریک.

مشکل مجوزها

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

پژوهشگران اشاره کردند که مدل مجوزهای پشت این خطای ایمنی (Safety Failure)، دقیقاً همان مدل مجوزهایی است که یک مهاجم از طریق تزریق پرامپت به‌طور عمدی از آن سوءاستفاده می‌کند. مشکل ایمنی و مشکل امنیتی یک ریشه مشترک دارند: عامل قدرت خودگردان بیش از حدی روی سیستم‌های حیاتی دارد. در همین راستا، سیستم Patronus تلاش می‌کند با ترکیب امتیازات تشخیص و سیاست‌های سختگیرانه، ایمنی مدل‌ها را در برابر این نوسانات تضمین کند.

گام بعدی شما

در سال ۲۰۲۶ هیچ راه حل کاملی برای این مشکل وجود ندارد و هر منبعی که ادعای خلاف این را کند، در حال اغراق است. با این حال، می‌توانید با اتخاذ این عادت‌ها ریسک خود را به‌طور معناداری کاهش دهید:

• مرحلهٔ بازبینی را فعال کنید: هرگز به عامل‌های کدنویسی اجازه ندهید بدون تأیید شما، دسترسی گسترده و دائمی برای اجرای دستورات شل یا دسترسی به اعتبارنامه‌ها داشته باشند، به‌ویژه زمانی که با محتوای نامعتبر مانند مخازن کلون شده (Cloned Repositories) کار می‌کنید.
• محتوای خارجی را نامعتبر بدانید: با فایل‌های README، کامنت‌ها و صفحات وب استخراج شده، همان‌گونه برخورد کنید که توسعه‌دهندگان خبره با داده‌های ورودی کاربران در یک اپلیکیشن وب برخورد می‌کنند.
• مجوزها را محدود کنید: به جای اعطای دسترسی‌های کلی برای صرفه‌جویی در زمان، به عامل فقط دسترسی‌هایی را بدهید که برای آن تسک خاص لازم است.
• ابزارها را فوراً به‌روزرسانی کنید: تمام CVEهای ذکر شده پس از افشا وصله شدند، اما این وصله‌ها فقط برای کاربرانی اعمال شد که نرم‌افزار خود را به‌روزرسانی کردند.

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

برای محافظت از محیط خود، همین امروز مجوزهای ابزار هوش مصنوعی خود را بررسی کرده و هرگونه قابلیت «اجرای خودکار» (auto-execute) برای دستورات ترمینال را غیرفعال کنید. اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.