Writer AI: ثغرة WriteOut تسرب رموز الجلسة الحساسة عبر المستأجرين

مقدمة تحليلية

في مايو 2026، كشفت شركة Sand Security عن ثغرة أمنية حرجة، أُطلق عليها اسم WriteOut، في منصة Writer AI لتمكين الذكاء الاصطناعي المؤسسي. هذه الثغرة، التي تم تصنيفها كـ 'فشل عزل الجلسات' (session isolation vulnerability)، كانت تسمح باختراق شامل عبر المستأجرين (cross-tenant compromise)، مما يعني أن مهاجماً واحداً كان قادراً على الوصول إلى بيانات مؤسسات متعددة من خلال استغلالها. الأمر تجاوز مجرد اختراق بيانات فردية؛ لقد هدد سلامة النظام بأكمله ومبدأ العزل الأساسي الذي تعتمد عليه الشركات الكبرى لحماية معلوماتها.

تفاصيل الثغرة مثيرة للقلق. كشف فريق Sand Security أن مهاجماً خارجياً، لا يملك أي وصول مسبق، كان بإمكانه السيطرة على أي مؤسسة تستخدم Writer AI داخل الشركات الرائدة في الصناعة، وكل ما يحتاجه هو رابط واحد. هذا الرابط، بمجرد النقر عليه من قبل مستخدم مسجل الدخول، كان كافياً لتشغيل سلسلة هجمات تنتهي بالاستيلاء على حساب الضحية بالكامل. الآثار المترتبة على ذلك كانت خطيرة، حيث كان المهاجم يستطيع الوصول إلى المحادثات الخاصة، الوثائق، والبيانات الحساسة الأخرى المتعلقة بالوكلاء (agents)، التكوينات، النماذج الخاصة، الموصلات (connectors)، وحتى بيانات اعتماد نماذج اللغة الكبيرة (LLM credentials).

التحليل التقني

القلب النابض لهذه الأزمة الأمنية هو ثغرة WriteOut، وهي ثغرة أمنية أحادية النقر (one-click vulnerability) تستغل طريقة معالجة Writer AI لرموز جلسات المستخدمين ضمن بيئة المعاينة الحية لوكلاء الذكاء الاصطناعي. تكمن خطورة WriteOut في قدرتها على تجاوز آليات العزل بين المستأجرين، مما يلغي فعلياً نموذج المسؤولية المشتركة الذي يُفترض أن يحمي بيانات المستخدمين. تعتمد Writer على ميزة 'المعاينة المباشرة' (live preview feature) التي تتيح للمستخدمين استعراض التطبيق عبر Writer Framework. هذه الميزة، المصممة لتسهيل التطوير، أصبحت نقطة ضعف حرجة.

تتمثل سلسلة الهجوم في الخطوات التالية:

• يبني المهاجم وكيلاً (agent) داخل حسابه الخاص في Writer AI مع تفعيل ميزة المعاينة المباشرة.
• يشارك المهاجم رابط المعاينة العامة لهذا الوكيل مع الضحية.
• عندما يفتح مستخدم Writer AI مسجل الدخول الرابط، يقوم متصفحه بإرفاق كوكيز جلسة Writer الخاصة به بالطلب.
• يرسل وكيل المعاينة (preview proxy) هذا الكوكي إلى صندوق رمل (sandbox) يتحكم فيه المهاجم.
• يقوم الكود الخبيث الموجود داخل صندوق الرمل الذي يسيطر عليه المهاجم بقراءة رمز الجلسة المعاد توجيهه واستخراجه (exfiltrates).
• يعيد المهاجم استخدام (replays) الرمز المسرب ويكتسب السيطرة الكاملة على حساب الضحية في Writer AI.

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

بعد الإفصاح المسؤول من Sand Security، عالجت Writer AI المشكلة بسرعة، حيث منعت إعادة توجيه كوكيز جلسة المستخدم إلى معاينات صندوق الرمل بالكامل، ونقلت المعاينات إلى مصدر معزول (isolated origin). هذا يضمن أن رمز الجلسة لم يعد متاحاً للوصول من داخل صندوق الرمل. أكدت Writer أنها قامت بإصلاح الثغرة في غضون 24 ساعة من الإخطار في مايو 2026، وأنه لا توجد أدلة على استغلال خبيث أو اختراق لبيانات العملاء.

السياق وتأثير السوق

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

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

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

رؤية Glitch4Techs

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