صفحة ويب مسمومة جعلت Grok يفكّ تشفير تعليمات مخفية ويسرّب المحادثة

في 19 أغسطس 2026، أكدت Adversa AI أن هجومها بالنقر الصفري على دردشة الويب Grok التابعة لـ xAI لا يزال يعمل، بعد أحد عشر أسبوعًا من إبلاغ الشركة به. يطلب مستخدم من Grok تلخيص صفحة ويب عادية. تحتوي الصفحة على نص مشفر AES-256-GCM، ومادة المفتاح اللازمة لفتحه، وتعليمة لفك التشفير. يشغّل Grok فك التشفير في بيئة Python المعزولة الخاصة به، ويعامل النص المستعاد كناتج لشيفرة نفّذها للتو، ثم يتبعها — فيجمّع عنوان URL يحمل اسم المستخدم، وموقعه التقريبي، ومستوى اشتراكه، ومطالبات تلك المحادثة، وفتح عنوان URL ذلك على عنوان اختاره المهاجم. لا يوجد نقر، ولا تأكيد، ولا تحذير. يمكن لأي مستخدم لوكيل دردشة الويب Grok على grok.com أن يُقاد عبر تلك السلسلة بواسطة صفحة مفخّخة. هذا السجل هو أحد المدخلات في أرشيف حوادث الذكاء الاصطناعي، الذي يضم مجموعة السجلات الكاملة ومصادرها والمدخلات المجاورة في هذه السلسلة.

السجل، ونوع الحدث الذي يصفه

يؤرّخ الأرشيف هذا المدخل بتاريخ 19 أغسطس 2026، وهو اليوم الذي أكّدت فيه Adversa أن الهجوم لا يزال يعمل في بيئة الإنتاج، ويصنّفه على أنه بحث: اكتشاف وإثبات مفهوم، وليس حدث نشر ولا خرقًا. نشرت Adversa AI المقال في اليوم التالي، 20 أغسطس 2026. الباحث المذكور هو Rony Utevsky. المنتج المتأثر هو دردشة Grok على الويب من xAI على grok.com، في التكوين الذي يجمع بين التصفح الوكيلي وصندوق تنفيذ أكواد Python، ويعمل بـ Grok 4.5 Fast.

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

التعليمات المشفرة غير واضحة للمُرشِّح المعدّ لالتقاطها.

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

هذا التمييز هو الجوهر التقني. إن حيل الترميز السابقة — base64 وROT13 والاستبدال البسيط — ضعيفة لأن نموذجًا قادرًا يستطيع فكّها داخل أوزانه نفسها، ما يعني أن النص المفكوك يظل محتوى مُولَّدًا يمكن تطبيق مرشّح عليه. ولا يمكن الالتفاف على التشفير القوي بتلك الطريقة. وكما يقول تحليل Adversa، على عكس base64 أو شيفرة استبدال، "لا يوجد اختصار يمكن لأوزان النموذج نفسها أن تتخذه هي الأخرى." الطريق العملي إلى النص الصريح هو تنفيذ خوارزمية التشفير في بيئة تشغيل النموذج.

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

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

"المفتاح" الذي طُلب من Grok بناؤه كان نموذجًا ذا حقول خاصة

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

ثم تمنح التعليمات السلسلة المحلولة وجهةً: يُقال لـ Grok إن يفتح عنوان URL «لجلب سياق إضافي»، مع نقل مخرجات القالب ضمن معاملات الاستعلام. ولأن أداة التنقل ذات صلاحيات مرتفعة والسبب المذكور يبدو روتينيًا، يخرج الطلب عبر قدرة التصفح الخاصة بالوكيل. وتقول Adversa إن أثر الاستدلال الذي نشرته يُظهر وجود x-auth-token كمعامل في ذلك الطلب. وخلاصتها للمسار هي أنه لم يكن هناك "حد فعّال للخروج أو بوابة موافقة" وأن "تعليمات مغسولة يتحكم فيها المهاجم تصل إلى إجراء خروج ذي صلاحيات مرتفعة دون إعاقة."

النطاق مهم هنا، لكن التغطية تُشوّشه. تصف عدة منافذ إعلامية هذه الخسارة بأنها «سجل الدردشة الكامل» الخاص بالمستخدم. أما وصف Adversa نفسه فهو أضيق: المطالبات الموجودة في المحادثة التي يجري تلخيصها، وكلها كانت بالفعل ضمن سياق النموذج. يقول الباحثون إنهم لم يختبروا ما إذا كان يمكن الوصول إلى محادثات أخرى أو ذاكرة الوكيل أو محتوى آخر. ويمكن تصور أن قالبًا يتناول سياق جلسة ما قد يُوسَّع بشكل معقول؛ لكن لم ينشر أحد أدلة على أنه جرى توسيعه.

أحد عشر أسبوعًا، واعتراف واحد

أبلغت Adversa عن سلسلة Grok إلى xAI مباشرةً وعبر HackerOne ضمن برنامج مكافآت الثغرات التابع للشركة في 3 يونيو 2026. أقرّت xAI بالتقرير لكنها، وفقًا لـ Adversa، لم تقدّم أي تفاصيل محددة ولا جدولًا زمنيًا للتخفيف. لم تحظَ محاولات المتابعة في 4 أغسطس و10 أغسطس بأي رد. وظلّت السلسلة قابلة لإعادة الإنتاج في 19 أغسطس. كشفت Adversa علنًا في 20 أغسطس وامتنعت عن نشر الحمولات التشغيلية للحد من إساءة الاستخدام.

عند الإفصاح، لم يكن هناك أي تصحيح، ولا CVE معرّف، ولا إرشاد من المورّد، ولا حل بديل موجّه للمستخدم. يصف تقرير The Register الصادر في 20 أغسطس، وتقرير Security Affairs الصادر في 23 أغسطس، ومذكرة Cloud Security Alliance الصادرة في اليوم نفسه، كل منها الوضع نفسه؛ ولا يحمل أي منها بيانًا من xAI يتجاوز الإقرار. ولا يذكر أي مصدر تمت مراجعته هنا، من الإفصاح وحتى أواخر أكتوبر 2026، أي إصلاح منذ ذلك الحين.

ما الذي يدعم النتيجة، وما الذي لا يدعمها

التغطية ليست ضئيلة. غطّتها The Register في يوم الإفصاح؛ وتابعت Security Affairs وCloud Security Alliance خلال ثلاثة أيام؛ كما غطّتها SecurityWeek وThe Cyber Express وDataconomy. وهذا حجم كبير من التغطية من منافذ مستقلة عن الباحث، وهو ما تستند إليه درجة الثقة A في الأرشيف: موثّقة جيدًا، والمصادر الأولية متوافقة.

إنه ليس تكرارًا مستقلًا، والفرق يستحق أن يُقال بوضوح. فكل رواية تعود في الأصل إلى إثبات مفهوم واحد أجراه فريق بحثي واحد. وتذكر مذكرة Cloud Security Alliance صراحةً أنها لم تعِد إنتاج الاستغلال ولم تقدّم أي اختبار معملي من عندها، وتُحاط ادعاءها بأن العيب يشمل البنية بأكملها بتحفظاتٍ إذ تجعله يستند إلى أدلة من «حفنة من الموردين». ولا يصف Security Affairs أي تأكيد من طرف ثالث. ويصف The Hacker News، الذي يحمل تقريره رقم النجاح الذي تُناقشه أدناه، شركة Adversa بأنها المصدر الوحيد لاكتشاف Grok. ولم ينشر أي فريق ثانٍ أي تجربة تشغيل ضد grok.com.

إن رقم النجاح الذي صاحب الكشف يحتاج إلى العناية نفسها. أفادت Adversa بنسبة نجاح تبلغ نحو 40% عبر نحو 20 محاولة منذ يونيو 2026، أي ثماني عمليات تسريب مكتملة، وعزت الإخفاقات إلى سوء تعامل Grok مع فك التشفير بدلًا من اعتراض مرشّح للحمولة. ويظهر ذلك الرقم في ملاحظة Cloud Security Alliance وفي تقرير The Hacker News، الذي يشير إلى أن المنشور الذي نشرته Adversa لا يحمل نسبة نجاح خاصة به. إنه رقم باحث عن اختبار باحث، وليس خاصية مقاسة للمنتج.

نفس التقنية ضد وكلاء آخرين

يعود تقرير Adversa أيضًا إلى عرض توضيحي سابق ضد Google Gemini في وضع Deep Thinking، المحدَّد بأنه Gemini 3 Flash (Web) على الخطة المدفوعة. كانت الحمولة بعد فك التشفير هناك عبارة عن تتبّع Python مُلفّق يحتوي على استدعاء وهمي بأسلوب API بدا وكأنه يعطّل سياسة الأمان؛ وأنتج النموذج إجابة من عدة فقرات حول صنع سلاح حارق، وكشف بصورة منفصلة عن تعليمات النظام الخاصة به. ويذكر The Hacker News أن عمل Gemini نُشر أولًا في 11 مارس 2026 وأُعيد إنتاجه خمس مرات من أصل خمس. ولم يتم إخطار Google، لأن كسر القيود (jailbreaks) يقع خارج برنامجها للإفصاح عن الثغرات.

لم تُسفر حالة Gemini عن أي تسريب بيانات قط، والسبب معماري لا حظّي: فواجهتها العامة لم تمنح النموذج وصولًا إلى مواقع خارجية عبر بايثون، لذا لم يكن هناك مسار خروج لنقل البيانات إلى الخارج. وهذا أوضح برهان على ما تتطلبه ثغرة Grok فعليًا — تنفيذ الشيفرة وأداة قادرة على الاتصال بالشبكة في السياق نفسه. كما تذكر Adversa أن معدل نجاح Gemini انخفض انخفاضًا حادًا بحلول أغسطس 2026، ولم تستطع نسب التغيير إلى المرشحات أو إصدارات النماذج أو كليهما. وفي الاختبار نفسه عبر النماذج، GPT-5 أخفق في تحليل تعليمات فك التشفير، وClaude Sonnet 4.5 فكّ تشفير الحمولة ثم أشار إلى النص الصريح باعتباره محاولة حقن.

في 6 أكتوبر 2026، نشرت Adversa متابعة تستخدم التقنية نفسها ضد GitHub Copilot CLI في وضع الطيار الآلي، حيث قادت صفحة مشفرة الوكيل إلى قراءة ملف .env.prod محلي وإرساله إلى الخارج في 28 ثانية. وقد غطّينا ذلك العرض التوضيحي بشكل منفصل. إنه سجل مختلف يستهدف منتجًا مختلفًا، وهو ينتمي إلى التقنية نفسها لا إلى هذا الإدخال.

ما يقول الباحثون إنه يجب تغييره

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

يضيف Cloud Security Alliance زاوية الكشف: إعادة تصنيف النص الصريح بعد أي خطوة فك ترميز أو فك تشفير بدلاً من قبلها فقط، ووضع علامة على استدعاءات PBKDF2 أو AES الشاذة الناشئة عن كود مكتوب بواسطة نموذج يتفاعل مع مستند خارجي، وفصل وكيل تنسيقي ذي صلاحيات عن نسخة معزولة تتعامل مع المحتوى المسترجع.

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

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