في نوفمبر 2025 كشفت Tenable Research عن سلسلة من الثغرات وتقنيات الهجوم في ChatGPT أظهرت كيف يمكن لهجمات Prompt Injection غير المباشرة أن تنتقل من محتوى موجود على الويب إلى سياق المحادثة، وفي بعض سيناريوهات إثبات المفهوم تصل إلى ذاكرة المستخدم أو تؤدي إلى تسريب معلومات خاصة.
لكن هذه القصة تحتاج إلى تحديث مهم: لم يكن البحث دليلًا على اختراق جماعي لكل مستخدمي ChatGPT، كما أن العناصر السبعة لم تكن سبع ثغرات CVE مستقلة. بعضها كان ثغرات في آليات محددة داخل المنتج، وبعضها تقنيات هجومية جمعها الباحثون لبناء سلاسل استغلال تجريبية. ومنذ ذلك الوقت غيّرت OpenAI عددًا من طبقات الحماية، بينما بقي Prompt Injection نفسه تحديًا أمنيًا مفتوحًا لأن أنظمة الذكاء الاصطناعي أصبحت تقرأ الويب والملفات وتستخدم الأدوات وتتصل بمصادر بيانات خارجية.
حتى 28 أغسطس 2026، الأفضل قراءة هذه الواقعة باعتبارها دراسة حالة مهمة في أمن ChatGPT والوكلاء الذكيين: ماذا اكتشفت Tenable؟ كيف كان تسريب البيانات ممكنًا؟ وما الذي تغيّر بعد الكشف؟
ماذا اكتشفت Tenable في ChatGPT؟
نشر الباحثان Moshe Bernstein وLiv Matan، بمشاركة باحثين آخرين من Tenable، تقريرًا بعنوان HackedGPT. ووصف التقرير سبع ثغرات وتقنيات ترتبط بالبحث وتصفح الويب وفحص عناوين URL وسياق المحادثة والذاكرة.
أهمية البحث لم تكن في وجود أمر سحري يستطيع سرقة بيانات أي حساب، بل في إظهار إمكانية تكوين سلسلة هجوم تبدأ بمحتوى يتحكم فيه طرف خارجي، ثم تجعل نظام الذكاء الاصطناعي يعامل هذا المحتوى كأنه تعليمات موثوقة، قبل محاولة الوصول إلى بيانات موجودة في سياق المستخدم أو إخراجها إلى جهة خارجية.
وهذا مثال واضح على Indirect Prompt Injection أو حقن الأوامر غير المباشر، الذي تصنفه OWASP ضمن أبرز مخاطر تطبيقات نماذج اللغة الكبيرة.
ما هو Prompt Injection ولماذا يختلف عن اختراق الحساب؟
Prompt Injection هو محاولة للتلاعب بسلوك نموذج الذكاء الاصطناعي من خلال تعليمات لا يفترض أن يتبعها. قد تأتي التعليمات مباشرة من المستخدم، أو بصورة غير مباشرة من صفحة ويب أو ملف أو بريد إلكتروني أو نتيجة بحث يقرأها النظام أثناء تنفيذ مهمة.
في الهجوم غير المباشر قد يطلب المستخدم مثلًا تلخيص صفحة طبيعية، بينما تحتوي الصفحة على نص آخر موجّه إلى نموذج الذكاء الاصطناعي وليس إلى القارئ. إذا لم تفصل المنظومة بصورة كافية بين البيانات التي يجب تحليلها والتعليمات التي يجب تنفيذها، فقد يحاول النموذج اتباع النص المزروع.
وهنا يجب التفريق بين نوعين من المخاطر:
- اختراق حساب ChatGPT: حصول المهاجم على كلمة المرور أو الجلسة أو بيانات تسجيل الدخول.
- Prompt Injection: خداع النظام نفسه أثناء معالجته محتوى غير موثوق، دون الحاجة بالضرورة إلى معرفة كلمة مرور المستخدم.
لذلك فإن المصادقة متعددة العوامل مهمة لحماية الحساب، لكنها ليست علاجًا مباشرًا لهجمات Prompt Injection.
الثغرات والتقنيات السبع التي عرضها بحث HackedGPT
1. حقن أوامر من مواقع يعتقد المستخدم أنها موثوقة
اختبر الباحثون سيناريو يطلب فيه المستخدم من ChatGPT تلخيص مقالة ويب، بينما يوجد داخل الصفحة أو قسم التعليقات محتوى يتضمن تعليمات موجهة إلى نظام التصفح.
المشكلة هنا أن المستخدم قد يثق بالموقع وبعملية التلخيص، في حين يأتي الأمر الخبيث من طرف ثالث يمكنه نشر تعليق أو محتوى داخل الصفحة.
2. Prompt Injection عبر نتائج البحث دون زيارة موقع يدويًا
أظهر البحث أن الخطر لا يقتصر على إعطاء ChatGPT رابطًا محددًا. فقد حاول الباحثون جعل محتوى خبيث يظهر ضمن المصادر التي يعثر عليها نظام البحث عند الإجابة عن سؤال طبيعي.
لهذا وُصف أحد السيناريوهات بأنه 0-click من منظور الضحية: المستخدم يطرح سؤالًا عاديًا، ثم يعثر نظام البحث على مصدر أعدّه المهاجم مسبقًا ويتعامل مع النص المزروع داخله.
هذا لا يعني أن أي نتيجة بحث تستطيع تلقائيًا سرقة البيانات، بل يصف نقطة الدخول التي استخدمت في إثبات المفهوم مع بقية أجزاء السلسلة.
3. حقن الأوامر باستخدام معامل q في رابط ChatGPT
وجدت Tenable أن واجهة ChatGPT كانت تسمح بوضع استعلام داخل معامل ?q= في عنوان URL وتشغيله بطريقة قد تجعل رابطًا مُعدًا مسبقًا نقطة دخول للهجوم.
هذه الحالة موثقة منفصلة في TRA-2025-22 وصنفتها Tenable بدرجة خطورة High.
وتوضح Tenable أن OpenAI غيّرت السلوك لاحقًا، بما في ذلك إضافة حماية ضد الإرسال التلقائي وتحسين فحص عناوين URL. لذلك لا ينبغي التعامل مع السلوك الموصوف في النسخة الأصلية من البحث على أنه وصف دقيق لواجهة ChatGPT الحالية.
4. تجاوز آلية فحص عناوين URL
كان ChatGPT يستخدم آلية وصفها الباحثون باسم url_safe للتحقق من عناوين URL قبل السماح بعرض موارد أو روابط معينة. اكتشف الباحثون طريقة لاستغلال روابط إعادة التوجيه المرتبطة بنتائج Bing لتجاوز الثقة الممنوحة لبعض العناوين.
كانت أهمية هذه الخطوة أنها تساعد في إنشاء قناة يمكن استخدامها ضمن سيناريو تسريب البيانات، بدل الاكتفاء بتغيير النص الذي ينتجه النموذج.
نشرت Tenable التفاصيل في TRA-2025-06. ولا تزال صفحة التنبيه تعرض أن حلًا لم يكن قد نُشر عند آخر حالة مسجلة فيها، لكن ذلك لا يكفي وحده للقول إن طريقة التجاوز القديمة ما زالت تعمل على البنية الحالية لـChatGPT، خصوصًا مع التغييرات الأمنية التي أعلنتها OpenAI لاحقًا حول منع تسريب البيانات عبر الروابط.
5. Conversation Injection
أطلق باحثو Tenable اسم Conversation Injection على تقنية تجعل محتوى قادمًا من عملية البحث أو التصفح يتحول إلى جزء مؤثر في سياق المحادثة.
الفكرة الأمنية الأهم هنا هي أن عزل أداة التصفح عن المعلومات الحساسة لا يكون كافيًا دائمًا إذا كان بإمكان ناتج تلك الأداة التأثير لاحقًا في النموذج الذي يملك سياقًا أوسع.
هذه المشكلة تتجاوز ChatGPT تحديدًا، لأنها تنطبق على تصميمات كثيرة لوكلاء الذكاء الاصطناعي: مكوّن منخفض الصلاحيات يقرأ محتوى غير موثوق، ثم ينقل مخرجاته إلى مكوّن آخر يملك بيانات أو أدوات أكثر حساسية.
6. إخفاء التعليمات الخبيثة عن المستخدم
أظهر البحث أيضًا تقنية تعتمد على طريقة عرض Markdown لإخفاء أجزاء من المحتوى عن الشاشة مع بقائها قابلة للمعالجة ضمن السياق.
النتيجة المهمة ليست خطأ Markdown بعينه، بل المبدأ الأمني: المحتوى الذي يراه نموذج الذكاء الاصطناعي قد لا يكون مطابقًا دائمًا لما يراه المستخدم بصريًا. ولهذا تشمل هجمات Prompt Injection الحديثة النص المخفي والـHTML والبيانات الوصفية والمستندات وحتى المدخلات متعددة الوسائط.
7. Memory Injection وتسميم ذاكرة ChatGPT
أخطر أجزاء البحث كان محاولة جعل التعليمات الخبيثة تستمر خارج المحادثة الحالية عبر ميزة الذاكرة. أظهر الباحثون إثبات مفهوم يستطيع فيه المحتوى المحقون التأثير في ما يتم حفظه كذاكرة، ثم استخدام تلك الذاكرة لاحقًا ضمن سيناريو تسريب معلومات.
وثقت Tenable هذه الحالة في TRA-2025-11 تحت اسم Command Memories Injection.
وتبقى الذاكرة نقطة حساسة لأنها تعمل عبر محادثات متعددة. وتوضح وثائق OpenAI الخاصة بالذاكرة أن المستخدم يستطيع مراجعة الذاكرة وحذفها أو تعطيلها، كما يمكن استخدام Temporary Chat عندما لا يريد أن تؤثر المحادثة في التخصيص المستقبلي.
كيف تحولت هذه العناصر إلى سيناريو لتسريب البيانات؟
قوة بحث Tenable ظهرت عند جمع عدة نقاط ضعف وتقنيات في سلسلة واحدة. بصورة مبسطة كان السيناريو الممكن يأخذ الشكل التالي:
- يضع المهاجم تعليمات خبيثة داخل صفحة أو محتوى يمكن لنظام البحث الوصول إليه.
- يطلب المستخدم من ChatGPT البحث عن موضوع أو تلخيص المحتوى.
- يدخل النص غير الموثوق إلى سياق معالجة النظام.
- تحاول التعليمات المحقونة تغيير سلوك النموذج.
- تُستخدم تقنيات إضافية لتجاوز ضوابط الروابط أو نقل التعليمات بين مكونات النظام.
- إذا أصبح النموذج قادرًا على الوصول إلى معلومات حساسة ضمن السياق، يحاول الهجوم إخراجها إلى مورد يتحكم فيه المهاجم.
هذه سلسلة تعتمد على عدة شروط. اكتشاف إمكانية تنفيذها في المختبر أمر مهم أمنيًا، لكنه يختلف عن إثبات وجود حملة واسعة تستخدمها ضد مستخدمي ChatGPT في العالم الحقيقي.
هل سُرقت بالفعل محادثات مستخدمي ChatGPT بهذه الطريقة؟
بحث Tenable يثبت إمكان إنشاء Proof of Concept لتسريب معلومات خاصة، لكنه لا يقدم دليلًا على اختراق جماعي لمستخدمي ChatGPT بهذه السلسلة.
وهذا فرق أساسي عند تقييم الأخبار الأمنية. وجود ثغرة أو PoC لا يعني تلقائيًا وجود استغلال نشط على نطاق واسع.
كما أن البحث الأصلي أُجري بدرجة كبيرة على ChatGPT المبني آنذاك على GPT-4o، ثم قالت Tenable في نوفمبر 2025 إنها أعادت اختبار عدد من السيناريوهات ووجدت أن بعضها ما زال قابلًا للتنفيذ مع GPT-5 في ذلك الوقت. هذه معلومة تاريخية تخص الإصدارات التي اختبرها الباحثون وليست إثباتًا لحالة نماذج ChatGPT الحالية في أغسطس 2026.
ما الذي تغيّر بعد بحث Tenable؟
أصلحت OpenAI أو عدّلت أجزاء من السلوك الذي اعتمدت عليه بعض السيناريوهات. على سبيل المثال، تسجل Tenable في TRA-2025-22 أن OpenAI حسّنت فحص الروابط وأضافت حماية مرتبطة بالإرسال التلقائي للاستعلامات.
لكن التطور الأكبر هو أن OpenAI نفسها أصبحت تصف Prompt Injection باعتباره تحديًا أمنيًا متطورًا لا يُحل بفلتر نصي واحد.
ومع انتقال ChatGPT من روبوت يجيب بالنص إلى أنظمة تستطيع البحث والتصفح واستخدام التطبيقات وتنفيذ إجراءات، اتجهت الحماية إلى نموذج Defense in Depth أو الدفاع متعدد الطبقات.
تشمل الإجراءات التي أعلنتها OpenAI في منتجاتها ووكلائها:
- تدريب النماذج على مقاومة التعليمات المزروعة في المحتوى الخارجي.
- مراقبة واكتشاف أنماط Prompt Injection أثناء تنفيذ المهام.
- طلب تأكيد المستخدم قبل بعض الإجراءات الحساسة.
- تقييد الوصول إلى الشبكة أو الأدوات في سياقات معينة.
- تقليل كمية البيانات والصلاحيات المتاحة للوكيل.
- استخدام وضع مراقبة للمستخدم في بعض السياقات الحساسة.
- بناء ضوابط مخصصة لمنع إخراج بيانات المستخدم سرًا عبر عناوين URL.
وفي مارس 2026 شرحت OpenAI في بحثها حول تصميم الوكلاء لمقاومة Prompt Injection أن الدفاع الأفضل لا يعتمد فقط على اكتشاف النص الخبيث، بل على تصميم النظام بحيث تكون قدرة المحتوى الخارجي على الوصول إلى البيانات أو تنفيذ إجراءات حساسة محدودة أصلًا.
حماية تسريب البيانات عبر الروابط
من أهم الدروس في HackedGPT أن النموذج لا يحتاج بالضرورة إلى إرسال ملف كامل إلى المهاجم حتى يحدث تسريب؛ ففي بعض التصميمات يمكن أن تحمل طلبات URL أو الموارد الخارجية أجزاء من معلومات المستخدم.
ولهذا نشرت OpenAI لاحقًا شرحًا مخصصًا حول حماية بيانات المستخدم عندما يفتح وكيل AI الروابط، موضحة أنها تبني ضوابط لمنع الوكيل من تمرير بيانات خاصة بصمت داخل عنوان المورد الذي يجلبه.
OpenAI تؤكد في الوقت نفسه أن حماية الرابط ليست ضمانًا بأن محتوى الموقع نفسه موثوق؛ لذلك تبقى الحاجة إلى الحماية على مستوى النموذج والأدوات والصلاحيات والمراقبة.
لماذا أصبح الخطر أكبر مع AI Agents والتطبيقات المتصلة؟
روبوت دردشة لا يستطيع سوى كتابة نص يملك تأثيرًا محدودًا مقارنة بوكيل يمكنه فتح البريد والملفات والتقويم والمتصفح وتنفيذ إجراءات نيابة عن المستخدم.
كل أداة جديدة تضيف منفعة، لكنها تضيف أيضًا Attack Surface جديدًا. فإذا نجح Prompt Injection في التأثير على نموذج يملك صلاحية قراءة بيانات حساسة أو استخدام أداة خارجية، تصبح نتيجة الخطأ أكثر أهمية.
ويظهر هذا المبدأ أيضًا في أنظمة Model Context Protocol. وقد شهد النظام البيئي بالفعل مخاطر من نوع مختلف مثل خادم MCP الخبيث الذي استهدف رسائل البريد الإلكتروني، وهو مثال على ضرورة عدم منح مكونات الوكلاء ثقة أو صلاحيات واسعة تلقائيًا.
هل يمكن القضاء نهائيًا على Prompt Injection؟
لا توجد حاليًا حماية واحدة تضمن منع كل حالات Prompt Injection. توضح OWASP أن المشكلة مرتبطة جزئيًا بطريقة معالجة نماذج اللغة للتعليمات والبيانات داخل السياق نفسه، وأن تقنيات مثل RAG أو Fine-tuning لا تلغي الخطر تلقائيًا.
ولهذا توصي OWASP في دليل منع Prompt Injection بمزيج من فصل المحتوى غير الموثوق، والتحقق من المدخلات والمخرجات، ومبدأ أقل صلاحية، والمراقبة، ووجود الإنسان في الحلقة عند تنفيذ الإجراءات الحساسة.
بمعنى آخر، الهدف الواقعي ليس افتراض أن النموذج لن يُخدع أبدًا، بل تصميم النظام بحيث لا تتحول محاولة خداع ناجحة إلى تسريب بيانات أو حذف ملفات أو تنفيذ إجراء خطير.
كيف تحمي بياناتك عند استخدام ChatGPT؟
لا يحتاج المستخدم العادي إلى التوقف عن استخدام البحث أو أدوات الذكاء الاصطناعي، لكن من المفيد التعامل معها كما تتعامل مع متصفح أو خدمة سحابية تملك وصولًا إلى بياناتك.
- لا تضع الأسرار في المحادثة دون حاجة: كلمات المرور ومفاتيح API وأكواد الاسترداد والبيانات المالية شديدة الحساسية لا ينبغي استخدامها كسياق عادي للنموذج.
- راجع الذاكرة: افحص ما يحفظه ChatGPT واحذف المعلومات التي لا تريد استخدامها مستقبلًا.
- استخدم Temporary Chat عند الحاجة: خصوصًا للمحادثات التي لا تريد إدخالها في التخصيص المستقبلي.
- قلل التطبيقات المتصلة: لا تمنح الوكيل وصولًا إلى البريد أو الملفات أو خدمات أخرى إذا لم تكن المهمة تحتاج إليها.
- استخدم تعليمات محددة: طلب مثل "ابحث عن هذه المعلومة فقط" أكثر أمانًا من منح وكيل صلاحية عامة مثل "راجع كل حساباتي وافعل ما تراه مناسبًا".
- راجع التأكيدات قبل الموافقة: لا توافق تلقائيًا على إرسال ملف أو رسالة أو مشاركة بيانات أو تنفيذ إجراء اقترحه الوكيل.
- توقف عند السلوك غير المتوقع: ظهور طلب غريب للوصول إلى خدمة أخرى أو إرسال معلومات لا تحتاجها المهمة إشارة تستحق المراجعة.
أما حماية الحساب نفسه فتظل مهمة أيضًا: كلمة مرور فريدة، ومصادقة متعددة العوامل، وتحديث الجهاز والمتصفح، ومراجعة الجلسات النشطة. ويمكن الرجوع إلى أفضل ممارسات الأمن السيبراني لتطبيق هذه الطبقات بصورة أوسع.
ماذا يجب على الشركات ومطوري تطبيقات AI فعله؟
الخطر الأكبر يكون عندما يُدمج نموذج اللغة مع قواعد بيانات أو بريد إلكتروني أو أنظمة داخلية أو أدوات تستطيع تنفيذ إجراءات. في هذه البيئات لا يكفي كتابة System Prompt يقول للنموذج "تجاهل التعليمات الخبيثة".
الأفضل بناء حدود أمنية خارج النموذج نفسه:
- منح كل أداة أقل قدر ممكن من الصلاحيات.
- استخدام صلاحيات قراءة فقط عندما لا تكون الكتابة ضرورية.
- فصل المحتوى الخارجي غير الموثوق عن التعليمات الموثوقة قدر الإمكان.
- التحقق من Tool Calls قبل تنفيذها.
- طلب موافقة بشرية على العمليات الحساسة أو غير القابلة للتراجع.
- منع النموذج من الوصول إلى أسرار لا يحتاج إليها أصلًا.
- تقييد الاتصالات الخارجية التي يمكن استخدامها لتسريب المعلومات.
- تسجيل ومراقبة استخدام الأدوات والموصلات.
- اختبار النظام دوريًا ضد Indirect Prompt Injection وليس ضد Jailbreak المباشر فقط.
- امتلاك طريقة سريعة لتعطيل أداة أو Connector عند اكتشاف سلوك غير طبيعي.
الخلاصة: ماذا بقي من قصة ثغرات ChatGPT في 2026؟
كشف HackedGPT في 2025 لم يكن مجرد قائمة "سبع ثغرات في ChatGPT"، بل مثالًا مبكرًا وواضحًا على مشكلة أوسع: عندما يستطيع نموذج الذكاء الاصطناعي قراءة محتوى يكتبه المهاجم وفي الوقت نفسه الوصول إلى معلومات أو أدوات تخص المستخدم، تصبح حدود الثقة بين التعليمات والبيانات والصلاحيات جزءًا أساسيًا من الأمن.
عالجت OpenAI بعض السلوكيات المحددة التي اعتمد عليها البحث وأضافت لاحقًا طبقات حماية أكبر للروابط والوكلاء والإجراءات الحساسة. وفي 2026 أضافت أيضًا إجراءات أمنية إضافية، من بينها Lockdown Mode وتنبيهات Elevated Risk للحالات التي تتطلب حماية أشد.
لكن Prompt Injection لم يتحول إلى مشكلة "تم إصلاحها وانتهت". OpenAI وOWASP والباحثون الأمنيون يتعاملون معه كفئة هجوم متطورة تتغير مع قدرات الوكلاء والأدوات المتصلة.
والدرس العملي للمستخدم والمؤسسة واحد: لا تجعل نجاح النموذج في فهم التعليمات مساويًا للثقة الأمنية فيه. قلل البيانات والصلاحيات المتاحة له، وافصل المحتوى غير الموثوق عن الإجراءات الحساسة، واجعل القرارات المهمة تمر عبر ضوابط لا تعتمد على النموذج وحده.