CometJacking هو الاسم الذي أطلقه باحثو LayerX في أكتوبر 2025 على Proof of Concept أظهر كيف يمكن لرابط مُعدّ بطريقة خبيثة أن يحاول تحويل مساعد متصفح Perplexity Comet من أداة تعمل لمصلحة المستخدم إلى Agent تنفذ تعليمات لم يقصدها. جوهر المشكلة لم يكن ثغرة Memory Corruption في Chromium ولا سرقة مباشرة لكلمات المرور من المتصفح، بل إساءة استغلال الحدود بين تعليمات المستخدم والبيانات غير الموثوقة التي تدخل إلى سياق نموذج الذكاء الاصطناعي.
الأهمية الحقيقية للحالة تتجاوز Comet نفسه. عندما يستطيع Browser Agent قراءة محتوى مواقع وخدمات مرتبطة ثم اتخاذ إجراءات عبر حسابات مسجل الدخول إليها المستخدم، فإن نجاح Prompt Injection لا يغيّر نص إجابة فقط؛ بل قد يؤثر في الأدوات والبيانات والإجراءات المتاحة للوكيل.
حتى أغسطس 2026، لا يوجد دليل علني موثوق يثبت أن Proof of Concept الأصلية لـCometJacking ما زالت تعمل على الإصدار الحالي من Comet بالطريقة نفسها. وفي المقابل، نشرت Perplexity لاحقًا دفاعات وقيود صلاحيات إضافية، بينما ما زالت جهات بحثية مثل Google وNIST تعتبر Indirect Prompt Injection مشكلة أمنية مهمة للـAI Agents عمومًا.
ما هو CometJacking؟
نشر باحثو LayerX البحث الأصلي حول CometJacking في 4 أكتوبر 2025. ووفق الباحثين، أمكن إنشاء رابط يحتوي على تعليمات تصل إلى مساعد Perplexity بطريقة تجعله يحاول الوصول إلى معلومات سبق أن أصبحت متاحة له، ثم إخراجها إلى وجهة يسيطر عليها الباحث.
هذا يجعل CometJacking أقرب إلى مشكلة Agent Hijacking عبر Prompt Injection من كونها Exploit تقليدية للمتصفح. المهاجم في النموذج المنشور لم يكن بحاجة إلى كسر Sandbox في Chromium أو تنفيذ Native Code داخل عملية المتصفح؛ كان يحاول استغلال قدرات الوكيل نفسها.
لفهم هذا النوع من المخاطر ضمن سياقه الأوسع، يشرح دليل أمن تطبيقات LLM وPrompt Injection وتسرب البيانات لماذا يجب التعامل مع المحتوى الخارجي باعتباره Untrusted Input حتى عندما يصل إلى النموذج عبر موقع أو مستند أو أداة موثوقة ظاهريًا.
كيف عمل Proof of Concept؟
اعتمد السيناريو الذي وصفته LayerX على خاصية تسمح ببدء تفاعل مع Perplexity من خلال رابط يحتوي على Query ومعلومات إضافية. صُمم الرابط بحيث تحمل معلماته تعليمات موجهة إلى المساعد بدل أن تكون مجرد بيانات عادية.
يمكن تبسيط سلسلة الخطر إلى أربع مراحل:
- وصول رابط مُعدّ مسبقًا إلى المستخدم: يمكن توزيعه عبر رسالة أو صفحة أو أي قناة يستطيع المهاجم من خلالها إقناع المستخدم بفتحه.
- دخول تعليمات المهاجم إلى سياق المساعد: بدلاً من التعامل معها كبيانات غير موثوقة فقط، أظهر الاختبار إمكانية تأثيرها في السلوك الذي يختاره Agent.
- محاولة استدعاء معلومات متاحة للوكيل: مثل بيانات مرتبطة بسياق سابق أو بخدمات يستطيع المساعد الوصول إليها وفق صلاحيات المستخدم.
- محاولة إخراج البيانات: أظهر الباحثون أن تحويل البيانات أو Encoding بسيط كان كافيًا في اختبارهم لتجاوز بعض فحوص منع Exfiltration التي واجهوها آنذاك.
المهم هنا هو المبدأ وليس Payload بعينها: إذا كان النظام يسمح للمحتوى غير الموثوق بتغيير نية Agent، وكان الوكيل يمتلك في الوقت نفسه صلاحية قراءة بيانات حساسة والاتصال بوجهات أخرى، فإن Prompt Injection قد تتحول من مشكلة في جودة الإجابة إلى مسار لتسريب البيانات.
هل كان الهجوم يحتاج إلى نقرة؟
نعم. السيناريو الذي نشرته LayerX اعتمد على أن يتفاعل المستخدم مع رابط مُعدّ للهجوم. لذلك فإن وصفه بأنه هجوم One Click لا يجعله Zero-Click.
هذه نقطة مهمة لأن العبارتين تصفان Threat Models مختلفين. في Zero-Click لا يحتاج الضحية عادة إلى فتح رابط أو تنفيذ إجراء لبدء الاستغلال، بينما CometJacking المنشورة اعتمدت على وصول المستخدم إلى الرابط الذي يحمل التعليمات.
يمكن استخدام التصيد أو الهندسة الاجتماعية كوسيلة لإيصال مثل هذا الرابط، لكن Prompt Injection هي الآلية التي تحاول التأثير في Agent بعد فتحه. لذلك لا ينبغي مساواة CometJacking بالتصيد التقليدي نفسه.
ما الفرق بين CometJacking وهجوم متصفح تقليدي؟
| الجانب | CometJacking | Exploit تقليدي للمتصفح | Phishing تقليدي |
|---|---|---|---|
| الهدف المباشر | سلوك AI Agent | Browser Engine أو مكوّن برمجي | المستخدم |
| الفئة الأساسية | Prompt Injection / Agent Hijacking | Software Vulnerability | Social Engineering |
| هل يتطلب Memory Corruption؟ | لا في البحث المنشور | قد يحدث حسب الثغرة | لا |
| مصدر الصلاحيات | الصلاحيات التي يملكها Agent والمستخدم | الصلاحيات المكتسبة بعد Exploitation | المعلومات التي يقدمها الضحية |
| الضرر المحتمل | قراءة أو إرسال بيانات متاحة للوكيل وتنفيذ Actions غير مقصودة | تنفيذ كود أو تجاوز Sandbox أو الوصول للبيانات | سرقة Credentials أو الأموال أو المعلومات |
ما البيانات التي كان يمكن أن تتعرض للخطر؟
يجب تجنب التعميم بأن CometJacking كانت قادرة تلقائيًا على سرقة «كل بيانات المتصفح». أثر الهجوم يعتمد على البيانات التي أصبحت متاحة للمساعد وعلى صلاحيات الخدمات التي يمكنه استخدامها.
ركز بحث LayerX على سيناريوهات مثل البريد والتقويم والمعلومات التي تعامل معها Assistant أو الخدمات المتصلة. فإذا كان المساعد لا يستطيع الوصول إلى خدمة معينة أصلًا، لا تتحول Prompt Injection وحدها إلى صلاحية سحرية تمنحه الوصول إليها.
وتوضح وثائق Perplexity الحالية حول خصوصية Comet Assistant أن بيانات مثل كلمات المرور وAutofill وCookies والملفات المحلية لا تُرفع افتراضيًا إلى Assistant لمجرد وجودها في المتصفح. في المقابل، قد يحتاج المساعد إلى إرسال Context محدد عند طلب تلخيص صفحة أو استخدام Tab أو تنفيذ مهمة تعتمد على البريد أو التقويم.
لذلك يجب تقييم Blast Radius بناءً على السؤال التالي: ما المعلومات والأدوات التي يستطيع Agent استخدامها في هذه الجلسة تحديدًا؟
هل CometJacking عبارة عن RCE أو CVE في Chromium؟
لا وفق البحث المنشور. لم تُعرض CometJacking كحالة Remote Code Execution داخل Chromium، ولم يكن جوهرها تجاوز Sandbox أو استغلال خطأ Memory Safety في محرك المتصفح.
المشكلة كانت في مستوى أعلى من الـStack: نموذج ذكاء اصطناعي يستقبل تعليمات وContext ويستطيع استخدام أدوات أو بيانات، ثم تتم محاولة تغيير قراراته عبر Input خبيث.
هذا الفرق مهم عند اختيار وسائل الحماية. تحديث Chromium ضروري لأمان المتصفح التقليدي، لكنه لا يعالج وحده Prompt Injection إذا بقي Agent قادرًا على الخلط بين بيانات خارجية وتعليمات موثوقة.
لماذا تعتبر Prompt Injection أخطر عندما يمتلك النموذج أدوات؟
في Chatbot بسيط، قد تؤدي Prompt Injection الناجحة إلى إجابة غير صحيحة أو كشف تعليمات داخلية. أما Agent فيمكن أن يمتلك Tools مثل التصفح، وقراءة محتوى صفحات، والانتقال بين مواقع، وملء نماذج، والتعامل مع خدمات أخرى.
هنا يظهر مفهوم Excessive Agency: كلما اتسع عدد الأدوات والبيانات والصلاحيات التي يستطيع النموذج استخدامها، اتسع الضرر المحتمل إذا نجح مهاجم في تغيير نية الوكيل.
ولهذا تصنف OWASP Prompt Injection ضمن المخاطر الأساسية لتطبيقات LLM، وتشير إلى أن Indirect Prompt Injection يمكن أن تأتي من مصادر خارجية مثل المواقع والملفات وأن تأثيرها يعتمد بدرجة كبيرة على الوظائف والبيانات المتاحة للنموذج.
ماذا حدث بعد كشف CometJacking؟
وفق LayerX، أُرسلت النتائج إلى Perplexity في 27 أغسطس 2025 ضمن Responsible Disclosure. وذكرت الشركة البحثية أن Perplexity صنفت البلاغ آنذاك على أنه لا يُظهر Security Impact قابلًا للتطبيق بحسب تقييمها.
لكن من الخطأ تحويل هذه النقطة التاريخية إلى وصف للحالة الحالية. فمنتجات Agentic AI تتغير بسرعة، وPerplexity نشرت بعد ذلك أعمالًا أمنية وضوابط إضافية لمعالجة فئة Prompt Injection.
BrowseSafe في ديسمبر 2025
في 2 ديسمبر 2025، نشرت Perplexity مشروع BrowseSafe، وهو بحث يركز على اكتشاف Prompt Injection في Browser Agents وبناء Defense-in-Depth حول المحتوى القادم من الويب.
تتضمن البنية التي شرحتها الشركة اعتبار أدوات استرجاع محتوى الويب مصادر غير موثوقة، وتشغيل Detector متخصص بالتوازي مع Agent، ثم تصعيد الحالات غير الواضحة إلى نماذج Reasoning أقوى. والأهم أن Perplexity نفسها توضح في البحث أن Detection Model واحدًا لا يمثل حلًا كاملًا، وأن الحماية تحتاج طبقات متعددة.
هذا تطور مهم، لكنه لا يثبت بمفرده أن Payload الخاصة بـCometJacking أُصلحت في كل إصدار لاحق، ولا ينبغي استخدامه كدليل على أن Prompt Injection أصبحت مشكلة محلولة.
ضوابط صلاحيات أكثر تفصيلًا في 2026
بحلول يوليو 2026، توثق Perplexity خيارات إدارية إضافية لـComet في المؤسسات. تسمح إدارة صلاحيات Comet Assistant بتعطيل قدرة المساعد على التحكم بالمتصفح أو تقييد نطاقات محددة إلى مستويات مثل:
- Browser Control: قراءة المحتوى وتنفيذ الإجراءات.
- Read Only: قراءة المحتوى دون تنفيذ Actions.
- No Access: منع الوصول إلى النطاق.
هذه الضوابط مهمة لأن تقليل Agency يقلل بدوره Blast Radius: حتى لو نجحت تعليمات غير موثوقة في التأثير على النموذج، فإن ما يستطيع فعله بعد ذلك يعتمد على صلاحياته الفعلية.
هل CometJacking ما زالت تعمل في 2026؟
لا توجد بيانات عامة كافية تسمح بالقول إن Proof of Concept الأصلية ما زالت تعمل على الإصدار الحالي من Comet. إعادة إثبات ذلك تتطلب اختبارًا جديدًا للإصدار الحالي ضمن Responsible Disclosure، وليس إعادة استخدام نتائج أكتوبر 2025 كأنها نتيجة معاصرة.
هناك أيضًا فرق بين بقاء فئة الخطر وبقاء Exploit محددة. قد يتوقف Payload معين بعد تحديث المنتج بينما تبقى Indirect Prompt Injection تحديًا أوسع يمكن أن تظهر له مسارات أخرى.
هذا ما تؤكده أبحاث مستقلة في 2026. ففي مارس، وصف NIST مخاطر Agent Hijacking بأنها مشكلة تواجه Agents التي تعالج مواقع ورسائل ومستودعات وبيانات خارجية، وقد تؤدي في الحالات الناجحة إلى إجراءات أو تسريب معلومات لم يقصدها المستخدم.
وفي يونيو 2026، خلص بحث Brave حول Indirect Prompt Injection إلى أن المشكلة ليست مرتبطة بكون النموذج Cloud أو Local؛ الخطر يظهر عندما تُجمع التعليمات الموثوقة والمحتويات غير الموثوقة داخل سياق يستطيع النموذج استخدامه لاتخاذ قرارات.
هل نشهد استغلالًا واسعًا لـPrompt Injection على الويب؟
الصورة المتاحة في 2026 أكثر دقة من القول إن AI Browsers تتعرض بالفعل لحملات CometJacking واسعة النطاق.
نشرت Google في أبريل 2026 تحليلًا لمحاولات Prompt Injection الموجودة على الويب العام. ووجد الباحثون أمثلة خبيثة تحاول تسريب البيانات أو تنفيذ أعمال تخريبية، لكنهم لم يرصدوا في العينة التي درسوها انتشارًا واسعًا للتقنيات المتقدمة التي ظهرت في أبحاث 2025.
كما أوضحت Google قيود البحث: المسح اعتمد على بيانات من الويب العام ولا يغطي جميع المنصات أو المحتوى المغلق. لذلك لا يمكن تحويل النتيجة إلى ادعاء بأن الهجمات غير موجودة، لكنها تعني أيضًا أنه لا يوجد أساس لاعتبار CometJacking حملة واسعة نشطة لمجرد وجود PoC منشورة.
كيف تقلل خطر Prompt Injection عند استخدام Comet أو Browser Agent؟
لا يستطيع المستخدم إصلاح Architecture الخاصة بالنموذج، لكنه يستطيع تقليل كمية البيانات والصلاحيات التي يمكن أن تتحول إلى أثر فعلي إذا أخطأ Agent.
1. لا تمنح Agent وصولًا لا تحتاجه
إذا كنت لا تحتاج أن يتعامل المساعد مع بريد عمل حساس أو تطبيق مالي أو لوحة إدارة، فمن الأفضل ألا تمنحه هذا النطاق من البداية. مبدأ Least Privilege ينطبق على AI Agents كما ينطبق على التطبيقات التقليدية.
2. تجنب Always Allow للإجراءات الحساسة
عندما يوفر المنتج خيار السماح لمرة واحدة بدلاً من منح إذن دائم، يكون Confirmation إضافيًا مفيدًا خصوصًا للمهام التي ترسل رسائل أو تعدل بيانات أو تتعامل مع خدمات حساسة.
3. امنع Assistant من المواقع الحساسة عند عدم الحاجة
توضح وثائق Comet الحالية أن المستخدم يستطيع تعطيل Assistant أو حظره على مواقع محددة. هذا يقلل احتمال أن يجمع Agent بين محتوى غير موثوق وبين Context من خدمة لا يحتاج إلى التعامل معها.
4. تعامل بحذر مع الروابط التي تفتح AI Assistant مباشرة
الرابط لا يصبح موثوقًا لمجرد أنه ينتهي إلى خدمة AI معروفة. إذا وصلتك رسالة غير متوقعة تطلب فتح رابط يشغّل Assistant أو يبدأ Query مجهزة مسبقًا، افحص المصدر والغرض قبل المتابعة.
5. راقب تغيّر نطاق المهمة
إذا طلبت من Agent تلخيص صفحة ثم بدأ يتحدث عن الانتقال إلى نطاق آخر أو إرسال بيانات أو ملء نموذج أو فتح خدمة غير مرتبطة بالمهمة، فهذا تغير في Task Scope يستحق التوقف والمراجعة.
6. حافظ على تحديث Comet
الإصدارات الجديدة قد تتضمن تحسينات في Browser Security والـAgent Guardrails. وتوضح وثائق Perplexity أن Comet يدعم التحديث التلقائي عند إعادة تشغيله، مع إمكانية التحقق من التحديث من صفحة About.
ما الذي ينبغي على المؤسسات فعله؟
استخدام AI Browser داخل مؤسسة يحتاج Threat Model أوسع من مجرد السماح بتثبيت متصفح جديد. يجب تحديد البيانات التي يستطيع Agent رؤيتها، والمواقع التي يمكنه التحكم بها، والإجراءات التي تتطلب Confirmation، والفرق بين حسابات منخفضة المخاطر وتطبيقات تحمل بيانات مالية أو أسرارًا تجارية.
من المفيد تطبيق عدة طبقات معًا:
- تقييد Browser Control إلى النطاقات التي تحتاجه فعلًا.
- استخدام Read Only عندما تكون القراءة كافية لإنجاز المهمة.
- اختيار No Access للخدمات الحساسة التي لا يحتاج Agent إلى استخدامها.
- منع إعطاء AI Assistant صلاحيات إدارية أو وصولًا واسعًا افتراضيًا.
- فرض تحديثات المتصفح وسياسات Extensions والمواقع عبر إدارة مركزية عندما تكون متاحة.
- مراجعة تدفقات البيانات بين Agent والخدمات المتصلة بدل التركيز على Prompt نفسها فقط.
- تدريب المستخدمين على أن تعليمات Agent ليست بالضرورة انعكاسًا لما طلبوه إذا كان قد عالج محتوى خارجيًا أثناء المهمة.
لماذا لا يكفي فلتر يبحث عن "Ignore previous instructions"؟
لأن Prompt Injection لا تحتاج إلى صيغة ثابتة. يمكن للمحتوى الخبيث استخدام إعادة صياغة أو لغة مختلفة أو سياق يبدو مشروعًا أو تعليمات موزعة داخل الصفحة.
بحث BrowseSafe نفسه وجد أن الهجمات الأكثر تمويهًا لغويًا أصعب في الاكتشاف من الأمثلة المباشرة. ولهذا تعتمد التصميمات الحديثة على طبقات مثل Classification وPolicy Enforcement وتقييد الأدوات وUser Confirmation وفصل نطاقات الوصول، بدل البحث عن كلمات محظورة فقط.
وتصف Google المشكلة بالطريقة نفسها تقريبًا: الدفاع ضد Indirect Prompt Injection يحتاج عملية مستمرة تشمل اكتشاف Attack Variants جديدة، وRed Teaming، وسياسات حتمية مثل URL Sanitization وTool Policies، إضافة إلى دفاعات مبنية على ML وLLM.
الدرس الأهم من CometJacking
أظهرت CometJacking تحولًا في مفهوم Browser Security. في المتصفح التقليدي، يعتمد جزء كبير من الحماية على حدود مثل Origin Isolation وPermissions وSandboxing. أما Agentic Browser فيضيف مكوّنًا يستطيع قراءة محتوى من Origin ثم اتخاذ قرار يؤدي إلى التفاعل مع Origin آخر نيابة عن المستخدم.
وهذا يجعل السؤال الأمني لا يقتصر على: «هل الموقع يستطيع الوصول إلى بيانات موقع آخر؟» بل يصبح أيضًا: هل يستطيع محتوى هذا الموقع إقناع Agent موثوقة بأن تصل هي إلى بيانات موقع آخر؟
هذه هي النقطة التي تجعل Prompt Injection مشكلة Architecture وليست مجرد حيلة نصية. كلما اقترب Agent من امتلاك قدرات المستخدم نفسها، أصبح الحفاظ على حدود واضحة بين Instruction وData، وبين Read وAct، وبين موقع موثوق ومحتوى غير موثوق أكثر أهمية.
الخلاصة
CometJacking كانت Proof of Concept منشورة في 2025 أظهرت إمكانية استخدام رابط مُعدّ لإدخال تعليمات إلى Perplexity Comet ومحاولة الوصول إلى معلومات متاحة للـAgent وتسريبها. لم تكن RCE في Chromium، ولم تكن Zero-Click، كما أن أثرها كان مرتبطًا بالصلاحيات والبيانات التي يستطيع Assistant استخدامها.
ومنذ ذلك الوقت تطورت دفاعات Comet؛ نشرت Perplexity BrowseSafe وأضافت ضوابط أكثر دقة لصلاحيات Assistant، خصوصًا في بيئات Enterprise. لكن لا يوجد أساس علني كافٍ للقول إن PoC الأصلية ما زالت تعمل في أغسطس 2026، تمامًا كما لا يوجد أساس للقول إن Prompt Injection أصبحت مشكلة محلولة.
الحالة الأدق اليوم هي أن CometJacking نفسها Case Study تاريخية، بينما Agent Hijacking وIndirect Prompt Injection ما زالتا جزءًا فعليًا من Threat Model للمتصفحات والوكلاء المعتمدين على الذكاء الاصطناعي. ولهذا تظل أفضل استراتيجية هي تقليل الصلاحيات، وفصل نطاقات الثقة، وطلب Confirmation للأعمال الحساسة، والتعامل مع كل محتوى خارجي يقرؤه Agent باعتباره غير موثوق حتى يثبت العكس.