یک روش حمله جدید نشان میدهد که چگونه یک درخواست ساده مانند «این صفحه را خلاصه کن» در نسخه وب Grok متعلق به xAI میتواند بدون هیچ تعامل اضافهای از سوی کاربر، به سرقت اطلاعاتی مانند نام کاربر، موقعیت مکانی تقریبی، نوع اشتراک و تاریخچه Promptهای گفتوگوی فعال منجر شود.
شرکت امنیتی Adversa AI در گزارشی که در اختیار Cyber Security News قرار داده، اعلام کرده است که این روش با نام Cryptographic Context Injection شناخته میشود. در این حمله، دستورات مهاجم داخل دادهای رمزنگاریشده با AES-256-GCM مخفی میشوند؛ به همین دلیل فیلترهای ورودی نمیتوانند محتوای واقعی آنها را بررسی کنند. سپس مدل وادار میشود داده را رمزگشایی کرده و دستورات استخراجشده را بهعنوان خروجی قابل اعتماد محیط اجرای کد خود در نظر بگیرد.
Rony Utevsky، محقق ارشد این پروژه، توضیح داده است که Payload روی یک صفحه وب کاملاً معمولی قرار میگیرد و شامل یک شیء JSON رمزنگاریشده، اطلاعات مربوط به کلید رمزگشایی و یک دستور کوتاه است که از Agent میخواهد داده را در محیط اجرای Python خود رمزگشایی کند.
Guardrailهای ایستا معمولاً متن را دستهبندی و تحلیل میکنند؛ اما الگوریتمهایی مانند PBKDF2 و AES-256-GCM را اجرا نمیکنند. برخلاف روشهای سادهتر مخفیسازی مانند Base64 یا رمزهای جایگزینی، یک داده رمزنگاریشده قوی را نمیتوان صرفاً از طریق دانش داخلی مدل بازیابی کرد و مدل برای مشاهده محتوای واقعی آن مجبور است از Interpreter استفاده کند.
مشکل اصلی زمانی رخ میدهد که Sandbox نتیجه رمزگشاییشده را برمیگرداند. در این مرحله Grok بهجای اینکه متن بهدستآمده را همچنان بهعنوان محتوای غیرقابل اعتماد یک صفحه وب در نظر بگیرد، با آن مشابه اطلاعات داخلی تولیدشده توسط خود سیستم رفتار میکند.
دستورات رمزگشاییشده سپس از Agent میخواهند اطلاعات خصوصی مربوط به Session را استخراج کرده و آنها را داخل یک «کلید رمزگشایی» جعلی قرار دهد. این کلید در واقع یک Template String است که اطلاعات قربانی، از جمله هویت و تاریخچه چت او، در آن جایگذاری میشود.
در ادامه به Grok دستور داده میشود برای «دریافت اطلاعات تکمیلی» یک URL را باز کند. ابزار Navigation دارای دسترسی ویژه Grok نیز آدرس تحت کنترل مهاجم را باز میکند؛ درحالیکه اطلاعات سرقتشده کاربر داخل Query String آن URL قرار گرفته است.
در Proof of Concept انجامشده روی Grok 4.5 Fast در grok.com، انتقال اطلاعات بدون نمایش هیچ پنجره تأیید یا هشدار قابل مشاهدهای انجام شد. به همین دلیل محققان این روش را یک حمله واقعی Zero-Click روی یک سیستم Production فعال توصیف کردهاند.
Adversa نخستین بار در ۳ ژوئن ۲۰۲۶ این آسیبپذیری را به xAI و برنامه HackerOne این شرکت گزارش کرد. xAI دریافت گزارش را تأیید کرد، اما هیچ زمانبندی مشخصی برای ارائه Mitigation اعلام نکرد. پیگیریهای انجامشده در ۴ و ۱۰ اوت نیز بدون پاسخ بیشتر باقی ماند.
به گفته محققان، آنها همچنان در ۱۹ اوت ۲۰۲۶ موفق به بازتولید کامل زنجیره حمله شدهاند. در حدود ۲۰ آزمایش انجامشده از ماه ژوئن، نرخ موفقیت حمله تقریباً ۴۰ درصد بوده است. موارد ناموفق نیز عمدتاً به دلیل خطا در فرآیند رمزگشایی رخ دادهاند، نه به دلیل شناسایی یا مسدود شدن Prompt مخرب.
در حال حاضر هیچ CVE، Patch عمومی یا گزارشی از سوءاستفاده عملی این آسیبپذیری در دنیای واقعی منتشر نشده است. محققان نیز Payloadهای عملیاتی حمله را منتشر نکردهاند.
همین ساختار رمزنگاریشده روی Google Gemini در حالت Deep Thinking نیز آزمایش شده است. طبق اطلاعات استخراجشده از متن System، مدل مورد آزمایش ظاهراً Gemini 3 Flash در نسخه پولی وب بوده است.
در این آزمایش، یک Prompt از Gemini میخواست یک Blob رمزنگاریشده را رمزگشایی کند. متن رمزگشاییشده شامل یک Python Traceback جعلی بود که در آن یک Callback ساختگی مربوط به Safety Policy و همچنین متنی با ظاهر Reasoning داخلی مدل قرار داشت.
از آنجا که مدل نتیجه Sandbox را بهعنوان خروجی متعلق به فرآیند داخلی خودش در نظر میگرفت، توانست محتوایی تولید کند که فیلترهای ایمنی معمولاً اجازه نمایش آن را نمیدهند. محققان همچنین با تغییر Payload موفق شدند مدل را وادار کنند بخشی از System Instructions خود را که نباید افشا شوند، بازتولید کند.
این موضوع به Google گزارش نشده است، زیرا Jailbreakها در محدوده برنامه Vulnerability این شرکت قرار نمیگیرند. بااینحال Adversa اعلام کرده که تا ماه اوت نرخ موفقیت این روش روی Gemini بهشدت کاهش پیدا کرده است؛ موضوعی که احتمالاً ناشی از تغییر در فیلترها یا مدل بوده است.
این یافته بخشی از یک روند گستردهتر در زمینه سرقت اطلاعات چت از Agentهای هوش مصنوعی است؛ سیستمهایی که قابلیت مرور وب، اجرای کد و استفاده از ابزارهای خارجی را دارند.
Prompt Injection دیگر صرفاً به معنای قرار دادن یک رشته مخرب داخل Prompt نیست. مسئله اصلی اکنون این است که Agent چه نوع Contextهایی را متعلق به خودش و قابل اعتماد در نظر میگیرد؛ از جمله خروجی Toolها، اطلاعات Runtime و دادههای تولیدشده توسط محیط اجرای کد.
Utevsky معتقد است راهحل اصلی این مشکل باید در Harness و معماری Agent اعمال شود، نه صرفاً در وزنهای مدل. از جمله اقدامات پیشنهادی میتوان به جدا نگه داشتن محتوای دریافتشده از وب از ابزارهای دارای دسترسی ویژه، دریافت تأیید کاربر پیش از مراجعه به مقصدهای جدید پس از مشخص شدن کامل آرگومانها، نگهداری Traceهای جداگانه برای هر Session و ایجاد هشدار برای زنجیرههایی شامل محتوای غیرقابل اعتماد → اجرای کد → ارسال غیرمنتظره اطلاعات به بیرون اشاره کرد.
تا زمانی که Grok بتواند منشأ و سطح اعتماد دادهها را در این زنجیره بهدرستی از یکدیگر تفکیک کند، کاربران باید درخواست خلاصهسازی صفحات وب ناشناس را عملی در نظر بگیرند که بالقوه میتواند اطلاعات موجود در گفتوگوی فعلی آنها را در معرض افشا قرار دهد.
منبع: https://cybersecuritynews.com/
