بازگشت به وبلاگ

وقتی پرامپت به شل تبدیل می‌شود؛ درس‌های دو آسیب‌پذیری بحرانی در Semantic Kernel مایکروسافت

مایکروسافت در ۷ مه ۲۰۲۶ دو آسیب‌پذیری CVE-2026-26030 و CVE-2026-25592 را در Semantic Kernel افشا کرد که در آن‌ها یک prompt injection ساده به اجرای کد روی میزبان ختم می‌شد؛ نمونه‌ای روشن از اینکه هر ابزار در دسترس مدل، یک سطح حملهٔ تازه است.

مایکروسافت در ۷ مه ۲۰۲۶ در وبلاگ امنیتی خود دو آسیب‌پذیری را در Semantic Kernel — چارچوبی که تیم‌ها برای ساخت عامل‌های هوشمند با پایتون و .NET به‌کار می‌برند — افشا کرد. نکتهٔ تکان‌دهنده سادگی حمله بود: به گفتهٔ پژوهشگران مایکروسافت، یک پرامپت کافی بود تا ماشین‌حساب ویندوز روی دستگاهی که عامل هوشمند روی آن اجرا می‌شد باز شود؛ بدون اکسپلویت مرورگر، فایل پیوست مخرب یا باگ خرابی حافظه.

آسیب‌پذیری اول، CVE-2026-26030، نسخه‌های پایتون پیش از 1.39.4 را تحت تأثیر قرار می‌داد و در افزونهٔ جست‌وجو (Search Plugin) و تابع فیلتر پیش‌فرض مخزن برداری درون‌حافظه‌ای بود. ریشهٔ مشکل ترکیب دو خطای رایج بود: درج مستقیم رشته در کد (unsafe string interpolation) و اتکا به یک «لیست سیاه» برای اعتبارسنجی. مهاجم با ساختن پرامپتی هدفمند می‌توانست محدودیت‌های AST پایتون را دور بزند — مثلاً با پیمایش سلسله‌مراتب کلاس‌ها از طریق __class__ و __subclasses__ — و به توابع خطرناکی مثل os.system() برسد.

آسیب‌پذیری دوم، CVE-2026-25592، مربوط به SDK دات‌نت (نسخه‌های قدیمی‌تر از 1.71.0) و افزونهٔ SessionsPythonPlugin بود. اینجا تابع DownloadFileAsync ناخواسته به‌عنوان ابزاری در دسترس مدل قرار گرفته بود؛ یعنی خود مدل می‌توانست آن را صدا بزند. نتیجه: امکان نوشتن فایل دلخواه روی میزبان از طریق prompt injection — برای مثال قرار دادن یک اسکریپت مخرب در پوشهٔ Startup ویندوز تا در ورود بعدی کاربر اجرا شود.

درس مشترک هر دو مورد این است که در معماری عامل‌های هوشمند، خروجی مدل و آرگومان‌هایی که مدل برای ابزارها می‌سازد باید ورودی «غیرقابل‌اعتماد» تلقی شوند. هر تابعی که به مدل می‌دهید در عمل یک endpoint عمومی است که مهاجم می‌تواند به‌صورت غیرمستقیم — از طریق متنی که مدل می‌خواند، مثل سند، صفحهٔ وب یا ایمیل — صدایش کند. این جمع‌بندی تفسیر ماست، اما با توصیه‌های خود مایکروسافت هم‌جهت است.

توصیه‌های مایکروسافت شامل این موارد است: ارتقا به نسخهٔ پایتون 1.39.4 یا بالاتر و .NET SDK نسخهٔ 1.71.0 یا بالاتر؛ استفاده از allowlist بر پایهٔ نوع گره‌های AST به‌جای لیست سیاه؛ اعتبارسنجی مسیر فایل با canonicalization؛ حذف ویژگی [KernelFunction] از عملیات حساس؛ و پایش نشانه‌های پس از نفوذ با تلمتری endpoint.

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

پیام کلی روشن است: امنیت یک دستیار هوشمند فقط به «مدل امن» وابسته نیست؛ به کدی وابسته است که مدل را به سیستم‌های واقعی وصل می‌کند. هرچه دسترسی عامل بیشتر باشد، هزینهٔ یک prompt injection موفق هم بالاتر است.