إجابة سريعة: يُعد تسريب بيانات Atlassian Rovo هجوم حقن أوامر غير مباشر (Indirect Prompt Injection)، كشفت عنه شركة PromptArmor لشركة Atlassian في 23 مايو 2026 ونشرت تفاصيله في 5 أغسطس 2026. تعمل تعليمات خفية داخل ملف تم رفعه على توجيه Rovo لتضمين محتوى من Jira وConfluence داخل رابط URL وفتحه، ليقوم المهاجم بقراءة تلك البيانات عبر سجلات خادمه. وتعطيل البحث على الويب لا يوقف هذا الهجوم.
إذا كان فريقك يستخدم Jira وConfluence مع تفعيل Rovo، فإن هذا الأمر يستحق 20 دقيقة من وقت مسؤول النظام. لا يتطلب الهجوم أي نقرة، أو موافقة من المستخدم، أو اختراق أي حساب؛ بل يكفي مجرد ملف مرفوع وطلب عادي واحد.
فيما يلي: تفاصيل الهجوم خطوة بخطوة، ولماذا يفشل خيار التعطيل الظاهر في إيقافه، وحالة التحديث الأمني حتى 27 أكتوبر 2026، وقائمة تحقق يمكنك تطبيقها اليوم. نحن نطور Sharkly، وهي مساحة عمل تتولى فيها وكلاء البرمجة مهامها من لوحة مشتركة، لذا نواجه التحدي ذاته. لا تزال مشكلة حقن الأوامر دون حل جذري في كل مكان، والسؤال الحقيقي هو ما الذي تتيحه كل أداة لوكيل ذكاء اصطناعي تم الاستيلاء عليه بالوصول إليه.
ماذا حدث: تفاصيل هجوم حقن الأوامر في Rovo خطوة بخطوة
يصف تقرير PromptArmor سلسلة هجوم تتألف من خمس خطوات:
- الملف المسموم: ترفع الضحية مستنداً بعنوان "Backlog Guide"، يحمل تعليمات خفية موجهة للنموذج، وليس للقارئ البشري.
- الطلب العادي: في وقت لاحق، تطلب الضحية من Rovo تنظيم تذاكر Jira الخاصة بها.
- البحث: يجلب Rovo تذاكر Jira وصفحات Confluence، ويقرأ الملف المسموم أثناء ذلك.
- التسريب: توجّه التعليمات Rovo لإلحاق هذا المحتوى برابط URL يتبع للمهاجم وفتحه عبر أداة جلب الروابط الخاصة به. فيسجل خادم المهاجم الطلب، ومعه كافة البيانات المسربة.
- التغطية على الأثر: تظهر للضحية اقتراحات اعتيادية للتذاكر دون وجود أي مؤشر على تسريب أي بيانات.
لا يتطلب الطلب الصادر أي موافقة بشرية، ولهذا تصفه PromptArmor بأنه هجوم بلا نقرات (Zero-click). وجاء في ملخصهم لنطاق الوصول: أي بيانات يستطيع الوكيل الوصول إليها داخل Atlassian، بما في ذلك المحتوى الوارد عبر موصلات الربط الخارجية (Connectors).
الملف ليس سوى نقطة دخول واحدة؛ إذ تشير PromptArmor أيضاً إلى تذاكر الدعم الفني الواردة من خارج الشركة، ونتائج البحث عند تفعيل البحث على الويب، وموصلات الطرف الثالث. فكل ما يقرأه Rovo يمكن أن يكون موضعاً لزرع تعليمات خبيثة.
لماذا لا يجدي تعطيل البحث على الويب نفعاً؟
توفر Atlassian للمسؤولين خياراً لتعطيل "البحث على الويب" (Web search) في Rovo، وقد أوقفته العديد من الفرق كإجراء احترازي. لكن PromptArmor تفيد بأن الهجوم يظل ناجحاً حتى مع إيقافه، لأن هذا الخيار لا يزيل الأداة المسؤولة عن فتح الروابط. كما أن تلك الأداة لا تتحقق من صحة الروابط التي ينشئها الوكيل بنفسه.
إن تسمية الإعداد باسم وظيفة معينة لا تعني بالضرورة إزالة تلك القدرة بالكامل.
تعرض صفحة إدارة الوصول إلى الويب والبحث لمسؤولي Atlassian الآن خيارين: يتحكم خيار "الوصول إلى الويب" (Web access) في قدرة Rovo على الوصول إلى صفحات الويب العامة، بينما يعتمد خيار "البحث على الويب" (Web search) عليه، وكلاهما مفعل افتراضياً. كما تحذر الصفحة من أنه "حتى لو تم تعطيل الوصول إلى الويب، فقد لا يتم حظر الأدوات المتصلة". [تحقق 2026-10-27: لا يؤكد أي مصدر عام ما إذا كان تعطيل الوصول إلى الويب يغلق مسار جلب الروابط الذي استخدمته PromptArmor. لا تخبر القراء بأنه يفعل ذلك.]
هل توجد قناة تسريب ثانية؟
نعم. تشير PromptArmor إلى أن Rovo يعرض صور Markdown في مخرجاته. وأي رابط صورة يشير إلى خادم المهاجم يسرب كل ما تم ترميزه داخله من بيانات فور قيام المتصفح بتحميل الصورة. نبهت PromptArmor إلى هذه القناة، لكنها لم تستعرض سلسلة استغلال كاملة لها عبر Rovo.
الجدول الزمني للإفصاح وحالة التحديث الأمني
| التاريخ | الحدث |
|---|---|
| 2026-05-23 | PromptArmor تكشف المشكلة لشركة Atlassian |
| 2026-05-25 | Atlassian تقر بالاستلام وتعين رقماً للحالة |
| 2026-06-04 | PromptArmor تتابع الأمر؛ دون رد جوهري |
| 2026-07-29 | PromptArmor تتابع مجدداً؛ دون رد جوهري |
| 2026-08-05 | PromptArmor تنشر التقرير؛ مع بقاء Rovo عرضة للثغرة |
حتى 27 أكتوبر 2026، لم نجد أي بيان أو تنبيه أمني أو إصلاح مؤكد من Atlassian لهذا المسار. كما تخلو سلسلة نقاشات Hacker News حول التقرير (306 نقاط، 138 تعليقاً) من أي رد من Atlassian أيضاً. [تحقق قبل النشر: أعد مراجعة التنبيهات الأمنية لـ Atlassian وصفحة PromptArmor للتأكد من وجود أي تحديث.]
ما وجه الاختلاف بين هذا الهجوم وRovoBlast؟
هما ثغرتان منفصلتان تماماً؛ فقد نشرت Varonis Threat Labs ثغرة RovoBlast، حيث استغل رابط مصمم خصيصاً معامل الرابط rovoChatPrompt لزرع تعليمات في Rovo Chat الخاص بالضحية. أبلغت Varonis عن ذلك عبر برنامج Bugcrowd الخاص بـ Atlassian وأفادت بأنه قد تم إصلاحها. كان RovoBlast يتطلب نقرة من الضحية، بينما يحتاج هجوم PromptArmor فقط إلى أن يؤدي المستخدم عمله اليومي المعتاد. وإصلاح إحداهما لا يعكس بالضرورة معالجة الأخرى.
النمط الكامن وراء الهجوم: الثالوث القاتل
أطلق سايمون ويليسون على هذا النمط اسم الثالوث القاتل (The lethal trifecta): وكيل يتمتع بصلاحية الوصول إلى بيانات خاصة، ومعرض لمحتوى يتحكم فيه المهاجم، ولديه وسيلة للتواصل الخارجي. وباكتمال هذه الأضلاع الثلاثة، يمكن للمهاجم خداعه لإرسال بياناتك إلى الخارج.
يمتلك Rovo في بيئات Jira وConfluence هذه الأضلاع الثلاثة بحكم تصميمه، وهو تحديداً ما يجعله أداة مفيدة.
خلصت نقاشات Hacker News إلى عدة حلول مقترحة:
- جلب الروابط التي يكتبها شخص أو تعيدها أداة موثوقة فقط: وتجنب الروابط التي يجمعها الوكيل بنفسه تماماً. أشار سايمون ويليسون إلى أنه عبر سجلات DNS ذات النطاق العام (Wildcard DNS)، يمكن تسريب البيانات عبر النطاق الفرعي (Subdomain) وحده.
- الروابط المفهرسة مسبقاً مفيدة، لكنها تسرب البيانات ببطء: أشار يوهان ريبيرغر (wunderwuzzi) إلى أن المهاجم لا يزال بإمكانه تسريب البيانات بمعدل حرف واحد لكل طلب.
- القوائم البيضاء للنطاقات فعالة مع الوكلاء محدودي المهام: إذا كان الوكيل يحتاج إلى ثلاثة نطاقات فقط، فلا تمنحه غيرها.
لا يُعد أي من هذه المقترحات علاجاً للنموذج في حد ذاته، بل تقتصر على تضييق مسار الاتصال الصادر، لأن النماذج لا تزال تنصاع للنصوص المحقونة أحياناً. ولهذا السبب، تضع منظمة OWASP حقن الأوامر في المرتبة الأولى ضمن قائمتها لمخاطر النماذج اللغوية الكبيرة تحت الرمز LLM01.
قائمة التحقق لأمان Rovo: ما يجب على مسؤولي Jira فحصه اليوم
تساهم كل خطوة في تقليص ضلع من أضلاع الثالوث القاتل.
- حدد بدقة كل ما يمكن لـ Rovo الوصول إليه: احصر كل تطبيق ومشروع ومساحة عمل (Space) وموصل خارجي. يلتزم Rovo بصلاحيات المستخدم، وبالتالي فإن أي جلسة يتم التلاعب بها ستصل إلى كل ما يملك صاحب الطلب حق رؤيته. وتذكر Atlassian أنه لا يمكن تعطيل Rovo نفسه كلياً، ولكن يمكن للمسؤولين حظر وصوله لكل تطبيق على حدة.
- ابحث عن المحتوى القادم من الخارج: تذاكر مكتب الخدمة، والرسائل المحولة إلى تذاكر (Email-to-issue)، والمرفقات، والمستندات المتزامنة تحمل جميعها نصوصاً لم يكتبها فريقك؛ وتلك هي واجهات حقن الأوامر لديك.
- دقق موصلات الربط: افصل الموصلات غير المستخدمة. وبالنسبة لـ Google Drive وSharePoint، استخدم القوائم المسموحة أو المحظورة الخاصة بالموصلات. واحرص على إبقاء المستندات القانونية، وملفات الموارد البشرية، والبيانات المالية، وسجلات الاستجابة للحوادث خارج نطاق الوصول، كما تنصح Varonis أيضاً.
- تحقق من خياري الويب معاً: أوقف خياري "البحث على الويب" و"الوصول إلى الويب" إذا لم يكن أحد بحاجة إليهما. ولا تعد أياً منهما حلاً قاطعاً لهذا الهجوم حتى تؤكد Atlassian ذلك رسمياً.
- راقب حركة البيانات الصادرة: تحقق من سجلات الخادم الوكيل (Proxy) للكشف عن أي نطاقات خارجية غير متوقعة للصور والروابط.
- اختبر النظام بتعليمة مزروعة: ضع أمراً غير ضار داخل تذكرة تجريبية تطلب من Rovo جلب رابط URL تتحكم فيه. فإذا ورد الطلب إلى خادمك، فقد حصلت على إجابتك.
- نبّه فريقك: وضّح لهم أن طلباً بسيطاً مثل "نظّم تذاكري" يمكنه تشغيل تعليمات خفية مزروعة داخل ملف مرفق.
إذا كان Jira هو المكان الذي تعتمد عليه وكلاء البرمجة لاستلام المهام، فاطلع على مقالنا حول إسناد تذاكر Jira إلى وكيل ذكاء اصطناعي.
التساؤلات ذاتها تنطبق على وكلاء البرمجة
تقرأ وكلاء البرمجة نصوصاً غير موثوقة طوال الوقت: نصوص المشكلات (Issues)، وتعليقات طلبات السحب (Pull requests)، وملفات README الخاصة بالحزم، والوثائق المجوبة. كما أنها تطلع على الشيفرة المصدرية وتمتلك عادةً اتصالاً بالشبكة؛ وهو ما يجسد الثالوث القاتل داخل سطر الأوامر بدلاً من واجهة المحادثة. وقد ناقشنا سابقاً سبب كون النماذج الأكثر تطوراً ليست بديلاً عن تحديد نطاق الصلاحيات في مقال حقن الأوامر وضوابط حماية الوكلاء.
لا توفر Sharkly حصانة للوكيل ضد هجمات الحقن، ولا توجد أداة يمكنها الادعاء بذلك اليوم؛ لكنها تمنحك وسيلة لتحديد نطاق الصلاحيات قبل بدء التشغيل. يعمل الوكلاء على حواسيب (Computers) تقوم بربطها، عبر خدمة محلية تنشئ اتصالاً للخارج، مما يغني في الإعدادات المعتادة عن فتح أي منافذ واردة. ولا يمكن للضيوف الوصول إلا إلى مساحات العمل (Spaces) التي أُضيفوا إليها صراحةً. كما تُنفذ إجراءات الطرف الثالث في مسارات الأتمتة عبر موصلات تفوضها بنفسك. وتنص الوثائق على عدم تخزين كلمات المرور أو الرموز المميزة (Tokens) أو المفاتيح نهائياً داخل تعليمات المهارات (Skill)، مع منح المستودعات الحد الأدنى من الصلاحيات التي تتطلبها المهمة.

يبحث الوكلاء وينفذون ويعدون التقارير، بينما يمنح البشر الصلاحيات ويعتمدون النتائج. لمزيد من التفاصيل، اقرأ مقالنا حول ما ينبغي وما لا ينبغي السماح لوكيل البرمجة بفعله ومقال أين تضع بوابات الموافقة.
خاتمة
ليس هجوم Rovo معقداً أو غريباً؛ فكل ما تطلبه هو ملف، وطلب اعتيادي، وأداة فتح روابط دون قيود على ما تفتحه، ولم يشمل خيار التعطيل الذي لجأت إليه أغلب الفرق تلك الأداة. وحتى كتابة هذه السطور، لا يوجد إصلاح مؤكد لهذا المسار المعتمد على المحتوى.
اجعل تحديد نطاق الصلاحيات وسيلة التحكم الأساسية لديك: حدد بدقة ما يقرأه Rovo، وأزل الموصلات غير المستخدمة، واختبر مسار البيانات الصادرة بنفسك. ثم اطرح ثلاثة أسئلة على كل وكيل يستخدمه فريقك: ما الذي يمكنه قراءته؟ وما هي النصوص غير الموثوقة التي تصله؟ وإلى أين يمكنه إرسال البيانات؟ ولوضع وكلاء البرمجة لديك على لوحة واحدة مع تحديد نطاق كل مهمة بدقة، فإن Sharkly متاح مجاناً للمؤسسات التي تضم حتى 5 أفراد.
الأسئلة الشائعة
ما هو هجوم تسريب بيانات Atlassian Rovo؟
هو هجوم حقن أوامر غير مباشر كشفت عنه PromptArmor في 5 أغسطس 2026؛ حيث تجبر تعليمات خفية أداة Rovo على إلحاق بيانات من Jira وConfluence برابط تابع للمهاجم وفتحه.
هل يحمي إيقاف تشغيل البحث على الويب في Rovo بياناتي؟
كلا، وفقاً لـ PromptArmor؛ فهذا الخيار لا يزيل الأداة المسؤولة عن فتح الروابط.
هل أصلحت Atlassian ثغرة حقن الأوامر في Rovo؟
لم نجد أي بيان أو إصلاح مؤكد من Atlassian للمسار الذي كشفت عنه PromptArmor حتى 27 أكتوبر 2026. في حين تم إصلاح ثغرة RovoBlast المنفصلة.
هل يتأثر Rovo Dev بهذا الهجوم؟
يُعد Rovo Dev وكيل البرمجة التابع لشركة Atlassian، وهو منتج مختلف عن Rovo في Jira وConfluence، ولم يتطرق تقرير PromptArmor إليه. راجع دليلنا حول الفئة المجانية لـ Rovo Dev.
هل وكلاء البرمجة معرضون للهجوم ذاته؟
نعم؛ فكل وكيل يقرأ نصوصاً غير موثوقة ولديه إمكانية الوصول إلى الشبكة يواجه الخطر عينه. لذا حدد ما يمكنه قراءته، وبيانات الاعتماد التي يحملها، والوجهات التي يمكنه إرسال البيانات إليها.


