n8n ترقّع ثغرة خروج من الـ sandbox بتقييم 8.7 في الإصدارين 2.31.5 و2.32.1
في الأدوات التي تنفّذ الكود عمدًا، يقوم الأمان كله على متانة الصندوق المعزول، وحين تحمل الأداة مفاتيح كل الأنظمة المتصلة بها يصبح اختراقها وصولًا إلى الخزنة كلها.
نشرت n8n، أداة أتمتة سير العمل التي يستضيفها كثيرون على خوادمهم، إصلاحًا لثغرة خروج من الـ sandbox تحمل الرقم GHSA-gv7g-jm28-cr3m، بتقييم CVSS 4.0 يبلغ 8.7، ولم يُخصص لها رقم CVE حتى 27 يوليو 2026. واكتشفها باحثون في 14 يوليو، وأُبلغت بها الشركة في 15 يوليو، وصدرت النسخ المصححة في 22 يوليو: 2.31.5 و2.32.1. والنسخ المتأثرة هي ما قبل 2.31.5، ومن 2.32.0 إلى ما قبل 2.32.1.
وتختلف هذه الثغرة عن أغلب الثغرات في نقطة أساسية. فـ n8n تسمح بطبيعتها بكتابة JavaScript داخل عقدة في سير العمل، وهذه هي الميزة التي يستخدمها الناس من أجلها وليست عيبًا. ولذلك يُنفَّذ هذا الكود داخل sandbox، أي بيئة معزولة يُفترض أن تمنعه من الوصول إلى نظام التشغيل.
فالمشكلة لم تكن في السماح بتشغيل الكود، بل في وجود مسار متبقٍ للخروج من البيئة المعزولة. والنتيجة أن صلاحية عادية، هي امتلاك حساب يستطيع تعديل سير عمل، كانت قد تتحول إلى تنفيذ أوامر على الخادم بصلاحيات عملية n8n نفسها.
ويتجاوز الضرر المحتمل حجم الأداة، لأن وظيفة n8n هي ربط الأنظمة بعضها ببعض. فهي تحتفظ بطبيعة عملها ببيانات الدخول (credentials) لكل ما يتصل بها: قواعد البيانات والبريد وبوابات الدفع والـ APIs. ولذلك فإن تنفيذ الأوامر على خادمها يعني الوصول إلى مخزن المفاتيح، لا إلى أداة واحدة.
وتنطبق الفكرة على كل أداة تنفّذ الكود عن قصد: الميزة والمخاطرة في السطر نفسه، ويصبح السؤال عمّن يملك صلاحية تعديل سير العمل سؤالًا أمنيًا بقدر ما هو إداري.
المصادر
من عدد الثلاثاء 14 صفر - 28 يوليو