حذّر باحثون في الأمن السيبراني من ثغرة شديدة الخطورة في منصة Flowise المفتوحة المصدر، وهي أداة تُستخدم لبناء تطبيقات الذكاء الاصطناعي والواجهات الحوارية ووكلاء التشغيل الذاتي. الثغرة، التي حُددت بدرجة خطورة مرتفعة للغاية، قد تتيح للمهاجم تنفيذ أوامر على الخادم عن بُعد في النسخ المستضافة ذاتياً من المنصة.
وتزداد أهمية هذا الخلل لأن Flowise تُستخدم كثيراً في بيئات العمل لتشغيل مساعدين داخليين، وتطبيقات الاسترجاع المعزّز بالذكاء الاصطناعي، وروبوتات المحادثة الموجهة للعملاء، إلى جانب وكلاء مرتبطين بأنظمة الشركة ومواردها. أي اختراق في هذه الطبقة قد يمتد سريعاً إلى بيانات وحسابات وخدمات متعددة.
كيف تعمل الثغرة
المشكلة تظهر في طريقة تنفيذ MCP stdio داخل Flowise، وهو جزء يربط المنصة بخوادم محلية عبر قنوات الإدخال والإخراج القياسية. هذا التصميم يسمح لوكلاء الذكاء الاصطناعي بالتفاعل مع الملفات، ومستودعات الشيفرة، وقواعد البيانات، والمتصفحات، وحتى بيانات الاعتماد المحلية.
بحسب الباحثين، تسمح المنصة في بعض الإعدادات بإدخال أوامر مخصصة داخل تكوين MCP. والخطر هنا أن هذه الأوامر لا تبقى داخل طبقة التطبيق، بل تُمرَّر في النهاية إلى نظام التشغيل نفسه. ونتيجة لذلك، يمكن لمهاجم استغلال الثغرة للحصول على تنفيذ أوامر بامتيازات عملية Flowise.
وفي البيئات المعتمدة على الحاويات، قد يؤدي ذلك عملياً إلى وصول أوسع داخل البيئة المستضيفة، ما يرفع من قيمة الهجوم بالنسبة للمهاجمين الذين يسعون إلى السيطرة على البنية التشغيلية المحيطة.
تأثير واسع على البيانات والأنظمة
أُعطيت الثغرة تصنيفاً أمنياً يقترب من الحد الأقصى، وهو ما يعكس حجم المخاطر المرتبطة بها. فنجاح الاستغلال قد يفتح الباب أمام الوصول إلى مفاتيح API، وقواعد البيانات، وموارد السحابة، وتطبيقات SaaS، وأي أصل آخر يمكن الوصول إليه من خلال Flowise.
هذا يعني أن الهجوم لا يقتصر على تعطل خدمة واحدة، بل قد يتحول إلى نقطة دخول داخلية تسمح للمهاجم بالتنقل بين الأنظمة أو جمع بيانات حساسة أو تشغيل أوامر إضافية ضمن البيئة نفسها.
ويُعد هذا النوع من الثغرات مثالاً واضحاً على المخاطر التي ترافق دمج أدوات الذكاء الاصطناعي مع الأنظمة التشغيلية، خصوصاً عندما تُمنح صلاحيات واسعة لخوادم محلية أو لمكونات يمكن للمستخدمين تكوينها مباشرة.
محاولات المعالجة لم تُغلق الباب بالكامل
أشارت التقارير إلى أن مطوري Flowise حاولوا تقليص الخطر عبر طبقات مختلفة من التحقق من المدخلات وتقييد بعض المسارات التي قد تقود إلى تنفيذ الأوامر. لكن الباحثين قالوا إن هذه المعالجات لم تُزل السبب الجذري للمشكلة، لأن الخلل الأساسي يبقى مرتبطاً بالسماح بتكوينات MCP stdio من مصادر قد لا تكون موثوقة بالكامل.
كما أوضحوا أن بعض ضوابط التحقق يمكن تجاوزها في ظروف معينة، ما يجعل الاعتماد عليها وحدها غير كافٍ لتأمين المنصة. وبحسب تقييمهم، فإن الحماية التي تعتمد فقط على الفلترة أو التحقق الشكلي قد تقلل المسارات الواضحة للهجوم، لكنها لا تمنع الاستغلال بشكل كامل.
وفي تحديثات لاحقة، أضيفت إجراءات أشد لفرض التحقق من بعض الأعلام والخيارات، إلا أن ذلك لم يلغِ الخطر بالكامل أيضاً. ووفقاً للباحثين، فإن وجود طبقات حماية جزئية أفضل من عدم وجود شيء، لكنه لا يعادل معالجة التصميم الذي يسمح أصلاً بإدخال أوامر قابلة للتنفيذ داخل MCP stdio.
لماذا تُعد هذه الثغرة مهمة لفرق الأمن
تكمن خطورة القضية في أن Flowise ليست مجرد أداة تطوير جانبية، بل قد تكون جزءاً أساسياً من بيئة الذكاء الاصطناعي داخل الشركات. وعندما تتصل هذه الأدوات بخدمات داخلية، ومستودعات بيانات، وحسابات سحابية، فإن أي تنفيذ أوامر غير مصرّح به يمكن أن يتحول إلى تسريب واسع أو تعطيل تشغيلي أو حتى اختراق متسلسل.
كما أن الخطر يرتفع في البيئات التي تسمح باستيراد chatflows أو نماذج عمل من مصادر خارجية، لأن هذه المدخلات قد تحمل إعدادات خبيثة أو روابط خفية تؤدي إلى تشغيل أوامر غير متوقعة. لذلك لا تكفي مراجعة الكود وحدها، بل يجب فحص الإعدادات وسلسلة الثقة كاملة.
وتصبح الحاجة أكبر في المؤسسات التي تبني طبقات أتمتة على وكلاء الذكاء الاصطناعي. فكلما زادت الصلاحيات الممنوحة للوكيل، زادت مساحة الضرر المحتملة إذا تم استغلال ثغرة في نقطة الربط بينه وبين النظام المحلي.
التوصية الأكثر أماناً
الاقتراح الأوضح من الباحثين هو تعطيل MCP stdio بالكامل واستبداله بوضع آخر أكثر أماناً، وهو SS E وفق الإعدادات المشار إليها. هذا الخيار يقلل الاعتماد على تنفيذ الأوامر المحلية عبر القناة نفسها، ويحدّ من فرص استغلال المسار الذي أدى إلى المشكلة.
أما المؤسسات التي لا تستطيع إيقاف الميزة مباشرة بسبب متطلبات تشغيلية، فعليها على الأقل تضييق نطاق الاستخدام، وتثبيت الحزم الموثوقة فقط، ومراجعة أي إعدادات أو استيرادات تأتي من مصادر غير معروفة. كما ينبغي التعامل بحذر مع أي chatflows واردة من خارج الفريق الداخلي، لأنها قد تكون نقطة إدخال لهجوم أوسع.
ويُتوقع أن يدفع هذا الحادث مزيداً من فرق التطوير إلى إعادة النظر في كيفية دمج أدوات الذكاء الاصطناعي مع الموارد المحلية. فالفائدة التشغيلية الكبيرة لا تلغي الحاجة إلى تصميم يضع الأمان في المقدمة، خاصة عندما تكون الأداة قادرة على الوصول إلى بيانات داخلية وحسابات سحابية وأنظمة إنتاجية.
خلاصة
تكشف الثغرة في Flowise عن تحدٍ متكرر في أدوات الذكاء الاصطناعي الحديثة: كلما زادت القدرة على الاتصال المباشر بالأنظمة والخدمات، زادت أيضاً احتمالات إساءة الاستخدام إذا لم تُبنَ آليات الحماية على أساس قوي منذ البداية. وفي حالة هذه المنصة، يبدو أن الإجراء الأكثر فعالية هو تقليل الاعتماد على MCP stdio أو تعطيله بالكامل حيثما أمكن، إلى أن تتوفر معالجة أعمق وأكثر صلابة.