تضع الصفحة الخبيثة حمولة تعليمات مشفّرة، إلى جانب المواد اللازمة لفك تشفيرها. وعندما يقرأ Grok الصفحة، ترى دفاعاته الأولية ضد حقن التعليمات نصاً مشفراً لا الأمر الصريح الذي يحتويه. بعد ذلك يُدفع الوكيل إلى تشغيل روتين لفك التشفير داخل بيئة تنفيذ Python أو التعليمات البرمجية الخاصة به.

وعندما تظهر التعليمات بعد فكها على هيئة مخرجات من أداة، قد يتعامل معها النموذج بصورة مختلفة عن تعليمات غير موثوقة مضمنة مباشرة في صفحة الويب.

وقالت Adversa إنها اختبرت الأسلوب ضد Grok 4.5 Fast على موقع grok.com. وذكرت رواية منفصلة للاختبارات أن الهجوم نجح في 40% من 20 محاولة بين يونيو وأغسطس 2026. وهذه النتيجة تصف بيئة اختبار الباحثين، ولا تعني أن كل محاولة أو كل جلسة استخدام لـGrok ستكون عرضة للاختراق.

كيف تعمل الصفحة المشفّرة؟

يتكون مسار الهجوم المبلغ عنه من مراحل متتابعة:

1. إخفاء الحمولة داخل الصفحة: يضع المهاجم على صفحة تبدو عادية نصاً مشفراً، وتعليمات لفك التشفير، ومفتاحاً أو مواداً لازمة لإتمام العملية. ويستخدم البناء المبلغ عنه مفاتيح مشتقة عبر PBKDF2 وتشفير AES-256-GCM.

2. تجاوز الفحص الأولي: تستطيع فلاتر Grok فحص المحتوى الظاهر، لكن التعليمات الخطرة تكون مخفية داخل بيانات مشفّرة. وبما أن التشفير القوي يحجب النص الأصلي، لا يستطيع النموذج تفسير الأمر الخبيث مباشرة خلال المرور الأول.

3. تنفيذ فك التشفير: عندما يطلب المستخدم من Grok تلخيص الصفحة أو تحليلها، يتبع الوكيل تعليماتها ويشغّل عملية فك التشفير داخل بيئة تنفيذ التعليمات البرمجية.

4. إعادة إدخال الأمر إلى سياق الوكيل: يظهر النص المفكوك بوصفه ناتجاً لعملية نفذتها أداة. وهنا تنشأ مشكلة مصدر المحتوى: إذ تنتقل تعليمات يتحكم بها المهاجم من صفحة غير موثوقة إلى سياق قد يتعامل معه الوكيل باعتباره نتيجة تشغيلية موثوقة.

5. الوصول إلى بيانات الجلسة: في نموذج إثبات المفهوم، طلبت التعليمات المفكوكة من Grok استخراج قيم مثل اسم المستخدم، وموقعه التقريبي، وفئة اشتراكه، والمطالبات الموجودة في سياق المحادثة المتاح للوكيل.

6. إرسال البيانات إلى الخارج: فتح Grok بعد ذلك عنوان URL يسيطر عليه المهاجم، ووضع البيانات المجموعة ضمن معاملات الرابط. ووفق العرض الذي أبلغت عنه Adversa، اكتملت العملية من دون تأكيد إضافي أو تحذير ظاهر.

لكن نطاق الخلل مهم. فالأدلة المتاحة تدعم الوصول إلى المطالبات والسياق اللذين أُتيحا للوكيل في الجلسة النشطة. لذلك لا ينبغي فهم عبارات مثل «سجل المحادثات الكامل» تلقائياً على أنها تعني الوصول إلى كل المحادثات المخزنة في حساب المستخدم.

متى أُبلغت xAI بالخلل؟

قالت Adversa إنها أبلغت xAI بالمشكلة عبر منصة HackerOne في 3 يونيو 2026، ثم أرسلت متابعتين لتنسيق الإفصاح في 4 أغسطس و10 أغسطس.

وحتى 19 أغسطس 2026، قالت Adversa إنها لم تتلق رداً جوهرياً، وإنها ما زالت قادرة على إعادة إنتاج الهجوم ضد Grok. ووصفت التقارير المتاحة في ذلك الوقت الخلل بأنه لا يملك إصلاحاً منشوراً، ولا رقم CVE عاماً، ولا حلاً مؤقتاً موجهاً للمستخدمين.

وتظل هذه الحالة، وفق المعلومات المتاحة، رواية الباحثين ووسائل الإعلام عن عملية الإفصاح، وليست نشرة أمنية عامة صادرة عن xAI. كما لا تثبت التقارير المقدمة أن مهاجمين استخدموا التقنية ضد مستخدمين حقيقيين خارج عروض الباحثين.

لماذا يخلق التشفير نقطة عمياء؟

تركز دفاعات حقن التعليمات التقليدية غالباً على اكتشاف اللغة المشبوهة في المحتوى الذي يسترجعه نظام الذكاء الاصطناعي. أما «حقن السياق التشفيري» فينقل الأمر الخطر إلى مرحلة لاحقة من المعالجة.

فالنموذج لا يحتاج إلى فهم الأمر الخبيث عند فحص الصفحة للمرة الأولى؛ يكفي أن يتبع تعليمات تبدو مفيدة، مثل تشغيل روتين لفك التشفير، داخل بيئة تشغيل يعتبرها موثوقة. ويصبح الأمر مقروءاً بعد تنفيذ تلك الخطوة، في وقت قد يكون فيه الوكيل قادراً بالفعل على الوصول إلى سياق خاص واستخدام أدوات التصفح أو إجراء طلبات شبكية.

لهذا السبب، يُفهم الخلل بصورة أدق باعتباره مشكلة في بنية الوكيل، وليس مجرد فشل في فلتر يبحث عن كلمات مفتاحية. فعندما يستطيع الوكيل قراءة محتوى خارجي، وتنفيذ التعليمات البرمجية، والوصول إلى بيانات الجلسة، واستدعاء أدوات الشبكة، يمكن لتعليمات خبيثة تحويل هذه الصلاحيات إلى قناة لاستخراج البيانات.

كيف ينسجم ذلك مع تهديدات وكلاء الذكاء الاصطناعي؟

تأتي إفادة Grok ضمن نمط أوسع تتلاعب فيه محتويات غير موثوقة بمساعدين يملكون وصولاً إلى بيانات حساسة أو أدوات قوية:

• بحث EchoLeak في Microsoft 365 Copilot: وثقت دراسة حالة EchoLeak ثغرة حقن تعليمات «من دون نقرة» في Microsoft 365 Copilot، أتاحت استخراج البيانات عن بُعد ومن دون مصادقة عبر رسالة بريد إلكتروني مُعدّة خصيصاً. وتتبع الثغرة بالمعرف CVE-2025-32711.
• بحث CoSnitch في Microsoft Copilot Personal: قال باحثو Varonis إن التلاعب المتكرر بطريقة استدلال Copilot قد يؤدي إلى إرسال بيانات حساسة إلى خادم خارجي، فضلاً عن تسميم الذاكرة المستمرة للمساعد.
• الهجمات على وكلاء البرمجة: وصفت أبحاث TrustFall من Adversa كيف يمكن لإعدادات خبيثة داخل مستودع برمجي أن تدفع خادم MCP يسيطر عليه المهاجم إلى تشغيل أوامر عبر مساعدين مثل Claude Code وGemini CLI وCursor CLI وGitHub Copilot CLI.

والقاسم المشترك هنا أن المهاجم لا يحتاج بالضرورة إلى اختراق النموذج الأساسي أو نظام التشغيل مباشرة. فهو يقدّم محتوى صُمم الوكيل أصلاً لقراءته، ثم يعتمد على صلاحيات الوكيل نفسه لاسترجاع المعلومات، أو تشغيل الأدوات، أو تعديل الحالة، أو إرسال طلب شبكي.

ما الدفاعات التي تشير إليها هذه الحالة؟

توضح التقنية المبلغ عنها أن حماية الوكلاء تحتاج إلى أكثر من تقوية فلاتر حقن التعليمات. ومن أبرز الضوابط المطلوبة:

• الفصل الواضح بين مصادر المحتوى: يجب إبقاء محتوى صفحات الويب ومخرجات الأدوات منفصلاً تقنياً وبصرياً عن تعليمات النظام وحالة التطبيق الموثوقة.
• تقييد تنفيذ التعليمات البرمجية: لا ينبغي السماح للمحتوى المسترجع بتشغيل عمليات فك تشفير أو أي تعليمات أخرى بلا سياسة دقيقة وبيئة معزولة.
• تطبيق مبدأ أقل الصلاحيات: ينبغي حصر السياق الخاص الذي يستطيع الوكيل الوصول إليه، ومنع مهام التلخيص العادية من كشف بيانات لا علاقة لها بالمهمة.
• طلب موافقة حقيقية على الإجراءات الحساسة: يجب أن تتطلب طلبات الشبكة التي تتضمن بيانات المستخدم أو المحادثة تأكيداً صريحاً ومفهوماً.
• التحكم في الاتصالات الصادرة: يمكن استخدام قوائم نطاقات مسموحة، وفحص عبر وسيط شبكي، وضوابط للخروج من الشبكة لمنع إرسال بيانات السياق إلى عناوين عشوائية.
• مراقبة سلسلة الأدوات: ينبغي تسجيل والتنبيه إلى التسلسلات غير المعتادة، مثل جلب صفحة، ثم تنفيذ تعليمات برمجية، ثم استخراج سياق، ثم فتح طلب خارجي.

والخلاصة بسيطة: لا يجوز لوكيل الذكاء الاصطناعي أن يعتبر المحتوى موثوقاً لمجرد أنه صدر عن أداة. ففي حالة Grok المبلغ عنها، نجح الهجوم في تحويل صفحة ويب إلى مسار لفك التشفير والتنفيذ، ثم استغلال صلاحيات الوكيل نفسه لإخراج سياق خاص من الجلسة.

تضع الصفحة الخبيثة حمولة تعليمات مشفّرة، إلى جانب المواد اللازمة لفك تشفيرها. وعندما يقرأ Grok الصفحة، ترى دفاعاته الأولية ضد حقن التعليمات نصاً مشفراً لا الأمر الصريح الذي يحتويه. بعد ذلك يُدفع الوكيل إلى تشغيل روتين لفك التشفير داخل بيئة تنفيذ Python أو التعليمات البرمجية الخاصة به.

وعندما تظهر التعليمات بعد فكها على هيئة مخرجات من أداة، قد يتعامل معها النموذج بصورة مختلفة عن تعليمات غير موثوقة مضمنة مباشرة في صفحة الويب.

وقالت Adversa إنها اختبرت الأسلوب ضد Grok 4.5 Fast على موقع grok.com. وذكرت رواية منفصلة للاختبارات أن الهجوم نجح في 40% من 20 محاولة بين يونيو وأغسطس 2026. وهذه النتيجة تصف بيئة اختبار الباحثين، ولا تعني أن كل محاولة أو كل جلسة استخدام لـGrok ستكون عرضة للاختراق.

كيف تعمل الصفحة المشفّرة؟

يتكون مسار الهجوم المبلغ عنه من مراحل متتابعة:

1. إخفاء الحمولة داخل الصفحة: يضع المهاجم على صفحة تبدو عادية نصاً مشفراً، وتعليمات لفك التشفير، ومفتاحاً أو مواداً لازمة لإتمام العملية. ويستخدم البناء المبلغ عنه مفاتيح مشتقة عبر PBKDF2 وتشفير AES-256-GCM.

2. تجاوز الفحص الأولي: تستطيع فلاتر Grok فحص المحتوى الظاهر، لكن التعليمات الخطرة تكون مخفية داخل بيانات مشفّرة. وبما أن التشفير القوي يحجب النص الأصلي، لا يستطيع النموذج تفسير الأمر الخبيث مباشرة خلال المرور الأول.

3. تنفيذ فك التشفير: عندما يطلب المستخدم من Grok تلخيص الصفحة أو تحليلها، يتبع الوكيل تعليماتها ويشغّل عملية فك التشفير داخل بيئة تنفيذ التعليمات البرمجية.

4. إعادة إدخال الأمر إلى سياق الوكيل: يظهر النص المفكوك بوصفه ناتجاً لعملية نفذتها أداة. وهنا تنشأ مشكلة مصدر المحتوى: إذ تنتقل تعليمات يتحكم بها المهاجم من صفحة غير موثوقة إلى سياق قد يتعامل معه الوكيل باعتباره نتيجة تشغيلية موثوقة.

5. الوصول إلى بيانات الجلسة: في نموذج إثبات المفهوم، طلبت التعليمات المفكوكة من Grok استخراج قيم مثل اسم المستخدم، وموقعه التقريبي، وفئة اشتراكه، والمطالبات الموجودة في سياق المحادثة المتاح للوكيل.

6. إرسال البيانات إلى الخارج: فتح Grok بعد ذلك عنوان URL يسيطر عليه المهاجم، ووضع البيانات المجموعة ضمن معاملات الرابط. ووفق العرض الذي أبلغت عنه Adversa، اكتملت العملية من دون تأكيد إضافي أو تحذير ظاهر.

لكن نطاق الخلل مهم. فالأدلة المتاحة تدعم الوصول إلى المطالبات والسياق اللذين أُتيحا للوكيل في الجلسة النشطة. لذلك لا ينبغي فهم عبارات مثل «سجل المحادثات الكامل» تلقائياً على أنها تعني الوصول إلى كل المحادثات المخزنة في حساب المستخدم.

متى أُبلغت xAI بالخلل؟

قالت Adversa إنها أبلغت xAI بالمشكلة عبر منصة HackerOne في 3 يونيو 2026، ثم أرسلت متابعتين لتنسيق الإفصاح في 4 أغسطس و10 أغسطس.

وحتى 19 أغسطس 2026، قالت Adversa إنها لم تتلق رداً جوهرياً، وإنها ما زالت قادرة على إعادة إنتاج الهجوم ضد Grok. ووصفت التقارير المتاحة في ذلك الوقت الخلل بأنه لا يملك إصلاحاً منشوراً، ولا رقم CVE عاماً، ولا حلاً مؤقتاً موجهاً للمستخدمين.

وتظل هذه الحالة، وفق المعلومات المتاحة، رواية الباحثين ووسائل الإعلام عن عملية الإفصاح، وليست نشرة أمنية عامة صادرة عن xAI. كما لا تثبت التقارير المقدمة أن مهاجمين استخدموا التقنية ضد مستخدمين حقيقيين خارج عروض الباحثين.

لماذا يخلق التشفير نقطة عمياء؟

تركز دفاعات حقن التعليمات التقليدية غالباً على اكتشاف اللغة المشبوهة في المحتوى الذي يسترجعه نظام الذكاء الاصطناعي. أما «حقن السياق التشفيري» فينقل الأمر الخطر إلى مرحلة لاحقة من المعالجة.

فالنموذج لا يحتاج إلى فهم الأمر الخبيث عند فحص الصفحة للمرة الأولى؛ يكفي أن يتبع تعليمات تبدو مفيدة، مثل تشغيل روتين لفك التشفير، داخل بيئة تشغيل يعتبرها موثوقة. ويصبح الأمر مقروءاً بعد تنفيذ تلك الخطوة، في وقت قد يكون فيه الوكيل قادراً بالفعل على الوصول إلى سياق خاص واستخدام أدوات التصفح أو إجراء طلبات شبكية.

لهذا السبب، يُفهم الخلل بصورة أدق باعتباره مشكلة في بنية الوكيل، وليس مجرد فشل في فلتر يبحث عن كلمات مفتاحية. فعندما يستطيع الوكيل قراءة محتوى خارجي، وتنفيذ التعليمات البرمجية، والوصول إلى بيانات الجلسة، واستدعاء أدوات الشبكة، يمكن لتعليمات خبيثة تحويل هذه الصلاحيات إلى قناة لاستخراج البيانات.

كيف ينسجم ذلك مع تهديدات وكلاء الذكاء الاصطناعي؟

تأتي إفادة Grok ضمن نمط أوسع تتلاعب فيه محتويات غير موثوقة بمساعدين يملكون وصولاً إلى بيانات حساسة أو أدوات قوية:

• بحث EchoLeak في Microsoft 365 Copilot: وثقت دراسة حالة EchoLeak ثغرة حقن تعليمات «من دون نقرة» في Microsoft 365 Copilot، أتاحت استخراج البيانات عن بُعد ومن دون مصادقة عبر رسالة بريد إلكتروني مُعدّة خصيصاً. وتتبع الثغرة بالمعرف CVE-2025-32711.
• بحث CoSnitch في Microsoft Copilot Personal: قال باحثو Varonis إن التلاعب المتكرر بطريقة استدلال Copilot قد يؤدي إلى إرسال بيانات حساسة إلى خادم خارجي، فضلاً عن تسميم الذاكرة المستمرة للمساعد.
• الهجمات على وكلاء البرمجة: وصفت أبحاث TrustFall من Adversa كيف يمكن لإعدادات خبيثة داخل مستودع برمجي أن تدفع خادم MCP يسيطر عليه المهاجم إلى تشغيل أوامر عبر مساعدين مثل Claude Code وGemini CLI وCursor CLI وGitHub Copilot CLI.

والقاسم المشترك هنا أن المهاجم لا يحتاج بالضرورة إلى اختراق النموذج الأساسي أو نظام التشغيل مباشرة. فهو يقدّم محتوى صُمم الوكيل أصلاً لقراءته، ثم يعتمد على صلاحيات الوكيل نفسه لاسترجاع المعلومات، أو تشغيل الأدوات، أو تعديل الحالة، أو إرسال طلب شبكي.

ما الدفاعات التي تشير إليها هذه الحالة؟

توضح التقنية المبلغ عنها أن حماية الوكلاء تحتاج إلى أكثر من تقوية فلاتر حقن التعليمات. ومن أبرز الضوابط المطلوبة:

• الفصل الواضح بين مصادر المحتوى: يجب إبقاء محتوى صفحات الويب ومخرجات الأدوات منفصلاً تقنياً وبصرياً عن تعليمات النظام وحالة التطبيق الموثوقة.
• تقييد تنفيذ التعليمات البرمجية: لا ينبغي السماح للمحتوى المسترجع بتشغيل عمليات فك تشفير أو أي تعليمات أخرى بلا سياسة دقيقة وبيئة معزولة.
• تطبيق مبدأ أقل الصلاحيات: ينبغي حصر السياق الخاص الذي يستطيع الوكيل الوصول إليه، ومنع مهام التلخيص العادية من كشف بيانات لا علاقة لها بالمهمة.
• طلب موافقة حقيقية على الإجراءات الحساسة: يجب أن تتطلب طلبات الشبكة التي تتضمن بيانات المستخدم أو المحادثة تأكيداً صريحاً ومفهوماً.
• التحكم في الاتصالات الصادرة: يمكن استخدام قوائم نطاقات مسموحة، وفحص عبر وسيط شبكي، وضوابط للخروج من الشبكة لمنع إرسال بيانات السياق إلى عناوين عشوائية.
• مراقبة سلسلة الأدوات: ينبغي تسجيل والتنبيه إلى التسلسلات غير المعتادة، مثل جلب صفحة، ثم تنفيذ تعليمات برمجية، ثم استخراج سياق، ثم فتح طلب خارجي.

والخلاصة بسيطة: لا يجوز لوكيل الذكاء الاصطناعي أن يعتبر المحتوى موثوقاً لمجرد أنه صدر عن أداة. ففي حالة Grok المبلغ عنها، نجح الهجوم في تحويل صفحة ويب إلى مسار لفك التشفير والتنفيذ، ثم استغلال صلاحيات الوكيل نفسه لإخراج سياق خاص من الجلسة.