ثغرة n8n تسمح بتسجيل الدخول من مُصدر آخر

ثغرة n8n الأمنية قد تسمح بتسجيل الدخول إلى حسابات مستخدمين من مُصدر هوية مختلف، ما يرفع المخاطر في بيئات المؤسسات متعددة الجهات.

ما هي ثغرة n8n الأمنية الجديدة؟

كشفت منصة n8n، المتخصصة في أتمتة سير العمل، عن خلل أمني خطير في آلية تسجيل الدخول عبر تبادل الرموز Token Exchange داخل الإصدارات المؤسسية. المشكلة تظهر عندما تكون المنصة مضبوطة للثقة في أكثر من مُصدر خارجي للرموز.

بحسب تفاصيل الحادثة، كانت المنصة تطابق المستخدم المحلي اعتماداً على قيمة sub فقط داخل رمز JWT، من دون التحقق من قيمة iss التي تحدد الجهة المُصدرة للرمز. هذا يعني أن رمزاً صالحاً من جهة A قد يمنح الوصول إلى حساب مستخدم تابع لجهة B إذا تشابه المعرّف بينهما.

كيف حدثت مشكلة تسجيل الدخول في n8n؟

ميزة Token Exchange صُممت أساساً للشركاء الذين يدمجون n8n داخل منتجاتهم، بحيث يدخل المستخدم إلى الخدمة من دون شاشة تسجيل دخول ثانية. عملياً، يرسل الشريك رمز JWT قصير العمر، ثم تتحقق n8n من صحته باستخدام مفتاح عام موثوق قبل ربطه بحساب محلي.

أين كان الخلل بالتحديد؟

الرمز نفسه قد يكون صحيحاً من الناحية التقنية، لكن آلية ربط الهوية كانت ناقصة. معيار JWT يوضح أن قيمة sub تكون فريدة فقط داخل نطاق الجهة المُصدرة، لذلك يجب التعامل مع هوية المستخدم على أنها زوج مكوّن من iss وsub معاً، وليس sub وحده.

• الخلل يؤثر على بيئات Enterprise فقط
• يتطلب تفعيل Token Exchange
• يشترط الثقة في مُصدرين خارجيين أو أكثر
• يسمح بانتحال حساب من جهة إصدار مختلفة

ما مدى خطورة ثغرة n8n على الشركات؟

الثغرة مسجلة تحت المعرف CVE-2026-59208، وقد أصدرت n8n الإصلاح في 24 يونيو 2026، بينما ظهر السجل العلني للثغرة في 9 يوليو 2026. هذا الفارق الزمني مهم لأنه يعني أن بعض المؤسسات ربما أصلحت الخلل قبل اتساع دائرة الانتباه إليه.

التقييمات الأولية تشير إلى خطورة مرتفعة نسبياً، لكن نطاق التأثر ليس عاماً. فالمشكلة لا تضرب كل مستخدمي المنصة، بل تستهدف سيناريوهات OEM والمؤسسات التي تستخدم أكثر من مزود هوية خارجي في نفس البيئة.

ماذا يجب على مستخدمي n8n فعله الآن؟

أول خطوة هي التأكد من تحديث n8n إلى النسخة التي تتضمن الإصلاح الأمني، خصوصاً إذا كانت المؤسسة تعتمد على Token Exchange في عمليات الدمج. كما يُنصح بمراجعة إعدادات المفاتيح الموثوقة وقائمة الجهات المصدرة المسموح لها بإرسال الرموز.

خطوات عملية لتقليل المخاطر

• تحديث المنصة فوراً إلى النسخة المصححة
• حصر الجهات المصدرة الموثوقة قدر الإمكان
• مراجعة سجلات الدخول بحثاً عن محاولات غير معتادة
• اختبار آلية ربط الهوية بين iss وsub بعد التحديث

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