تتناول هذه المقالة ثغرة تبادل الرموز في منصة n8n، وكيف يمكن أن تؤثر على أمان المستخدمين من خلال السماح للمهاجمين بتسجيل الدخول كأشخاص آخرين.
ثغرة تبادل الرموز في n8n قد تسمح للمهاجمين بتسجيل الدخول كالمستخدمين من مصدر آخر
منصة n8n لأتمتة سير العمل منحت حسابات خاطئة عند تسجيل الدخول. في النسخ المؤسسية التي تم تكوينها لتثق في أكثر من مصدر رموز خارجي واحد، تم مطابقة JWT الوارد مع مستخدم محلي بناءً على قيمة sub وحدها وتجاهل iss.
تم تسجيل الدخول كأحدهم باستخدام رمز صالح من المصدر A يحمل sub ينتمي إلى شخص تحت المصدر B. لم يكن هناك أي دور لكلمة المرور. أصدرت n8n الإصلاح في 24 يونيو.
تتبع الثغرة برقم CVE-2026-59208. لم يتم نشر سجل CVE حتى 9 يوليو. تعزو n8n التقرير إلى حساب GitHub bearsyankees، الذي يسرد Strix، التي تصنع وكيل اختبار اختراق بالذكاء الاصطناعي.
تقول Strix إنها أشارت إلى أن الوكيل في تدفق تبادل الرموز ووجدت خطأ ربط الهوية هناك.
مصدّران، حساب واحد
تبادل الرموز هو مسار n8n المؤسسي لشركاء OEM الذين يدمجون المنتج، وهو تنفيذ RFC 8693 الذي يوفر لمستخدميهم شاشة تسجيل دخول ثانية.
يوقع الشريك JWT قصير العمر بمفتاحه الخاص، تتحقق n8n منه مقابل مفتاح عام مُكون، وتطابق المطالبات مع حساب محلي، ويدخل المستخدم. يتم إدخال المفاتيح الموثوقة في N8N_TOKEN_EXCHANGE_TRUSTED_KEYS، ولا تزال وثائق النشر تصنف هذه الميزة على أنها في مرحلة المعاينة.
يتحقق الرمز نفسه. المطابقة هي الخطأ. قيمة sub مضمونة فحسب أن تكون فريدة داخل المصدر الذي أصدرها. تطلب RFC 7519 أن تكون “محددة لتكون فريدة محليًا في سياق المصدر” أو فريدة عالميًا. وبالتالي، فإن معرف المستخدم هو الزوج، iss بالإضافة إلى sub.
ركزت n8n على نصفه. لا شيء يمنع مصدرين من إصدار نفس سلسلة الموضوع، وعندما يحدث ذلك، ينتهي الأمر بكلاهما على حساب n8n واحد.
ما مدى خطورة ذلك
تصل الثغرة إلى نسخة فقط إذا تم تشغيل تبادل الرموز وكانت الإعدادات تثق في مصدرين خارجيين على الأقل. تقول n8n إن لا شيء آخر يتأثر. تبادل الرموز مخصص للمؤسسات ولا يزال مُعلمًا كمعاينة، لذا فإن مجموعة التعرض صغيرة ومحددة: نشرات OEM، حيث يعتبر ثقة مصدر ثانٍ تكوينًا مدعومًا.
ما لا تحدده الإرشادات هو كيفية حصول المهاجم على الرمز. تقول فقط إنه يمكنهم الحصول على واحد. السؤال العملي هو ما إذا كان بإمكان مستخدم عادي في مصدر موثوق التأثير على sub الذي يتلقاه. لا تسجل السجلات العامة ذلك. يُحدد متجه CVSS 4.0 الخاص بـ GitHub متطلبات الهجوم على أنها موجودة ويتوقف عند هذا الحد.
خصص GitHub ذلك المتجه. بصفتها CNA هنا، وضعت CVE-2026-59208 عند 7.6 على CVSS 4.0، مرتفع. تضع NVD نفس الخطأ عند 6.8 على CVSS 3.1، متوسط، ولم تصدر تقييمًا 4.0 على الإطلاق؛ يحمل سجلها CWE-287 وCWE-346. تسجل تقييم SSVC الخاص بـ CISA في 13 يوليو استغلالًا على أنه لا شيء، ووجدت The Hacker News عدم وجود دليل عام على مفهوم إثبات في عمليات البحث في 16 يوليو.
قبل أسبوعين من الإصلاح في 24 يونيو، قام القائمون بالصيانة بإصلاح CVE-2026-54305، وهو خطأ آخر مخصص للمؤسسات فقط. يسمح لأي مستخدم مصدق بتجاوز أو إلغاء رموز OAuth المخزنة لمستخدم آخر من خلال نقاط نهاية بيانات الاعتماد الديناميكية. كان ذلك نقصًا في فحص الملكية، وليس ربط الهوية. خطأ مختلف، نفس السطح.
تواصلت The Hacker News مع n8n لتأكيد نطاق وتأثير CVE-2026-59208 وسنقوم بتحديث هذه القصة بأي رد.
تحديث أو تقليص قائمة المصادر
تؤثر CVE-2026-59208 على كل إصدار من n8n أقل من 2.27.4 والإصدار 2.28.0. هبط الإصلاح أولاً في 2.27.4 و2.28.1. تلك هي القاعدة. في 16 يوليو، حمل حزمة npm الخاصة بـ n8n الإصدار 2.30.6 على كل من العلامات الأخيرة والثابتة. تُصدر تحديثًا صغيرًا جديدًا معظم الأسابيع حسب حسابها، لذا تحقق من العلامة وخذ أحدث إصدار ثابت يدعمه نشراتك.
إذا كان التحديث يجب أن ينتظر، اعمل على ما تقوم بتشغيله: يحمل N8N_TOKEN_EXCHANGE_TRUSTED_KEYS المفاتيح الموقعة الموثوقة، ويضبط علم المعاينة المنفصل ما إذا كان تبادل الرموز قيد التشغيل على الإطلاق. قلل إلى مصدر موثوق واحد، أو أوقف الميزة.
تدعو الإرشادات إلى اتخاذ تدابير قصيرة الأجل وتقول إن أيًا منهما لا يعالج المخاطر بالكامل. هذا هو النص القياسي، المتطابق في ثلاث إرشادات أخرى على الأقل من n8n، بما في ذلك تلك التي صدرت في 10 يونيو. وفقًا لبيان نطاق n8n نفسه، فإن النسخة التي تم إيقاف تشغيل تبادل الرموز بها ليست متأثرة.
لا تذكر ملاحظات الإصدار الإصلاح. تحقق The Hacker News من كليهما: تغطي سجلات التغيير بين 2.27.4 و2.28.1 إصلاح استيراد Python، وترقية عقدة Google Ads، وفحص سير العمل بالذكاء الاصطناعي، وتغيير بناء العقدة، ولا شيء عن الهوية.
تعيش الإرشادات هنا. إذا كانت قرارات التحديث الخاصة بك تعتمد على سجلات التغيير، فهذا هو نوع الإصلاح الذي ينزلق.
من المهم أن تبقى على اطلاع دائم بالتحديثات الأمنية والإصلاحات الخاصة بالثغرات، لضمان أمان بياناتك وخصوصيتك عند استخدام منصات مثل n8n.
