CVE-2026-21877: لماذا درجة CVSS 9.9 مبررة
تُصنَّف الثغرة ضمن CWE-434 — رفع ملف بنوع خطير دون قيود. تتيح عقدة Git في n8n، في ظروف معينة، لمستخدم مصادق كتابة ملف عشوائي على نظام ملفات الخادم. يستطيع المهاجم كتابة سكريبت في مسار ينفذه عملية n8n ثم تشغيله عبر سير عمل لتحقيق تنفيذ كود عن بُعد.
ناقل الهجوم شبكي ولا يتطلب أي تفاعل إضافي من المستخدم. النطاق يتغير (scope: Changed) مما يعني أن الأثر يتجاوز عملية n8n: السرية والسلامة والتوافر للخادم كلها معرضة للاختراق. بلغت درجة EPSS 5.449% (البيرسنتيل 92) مما يدل على احتمال عالٍ للاستغلال الفعلي خلال 30 يوماً.
يشمل التنبيه AL26-001 أيضاً CVE-2026-21858 (تحقق غير كافٍ للمدخلات في طلبات webhook، CVSS 10.0 وفق بعض المصادر) وCVE-2025-68613 (عزل غير كافٍ للتعبيرات في إعدادات سير العمل). يجب معالجة الثلاث ضمن نطاق تصحيح واحد.
من هو معرض للخطر وفي أي نطاق من الإصدارات
- جميع نسخ n8n المستضافة ذاتياً من 0.123.0 وحتى ما دون 1.121.3 معرضة لـ CVE-2026-21877 وفق التنبيه GHSA-v364-rw7m-3263 على GitHub.
- النسخ خلف وكيل عكسي ليست محمية: الثغرة تستلزم مصادقة فحسب — حساب مخترق أو موظف داخلي ضار يكفي؛ محيط الشبكة لا يغير نطاق التعرض.
- كلا نشري Docker وnpm متأثران: الناقل هو عقدة Git الموجودة في جميع توزيعات n8n بصرف النظر عن طريقة التثبيت.
- نسخ n8n Cloud المُدارة من n8n.io تلقت التحديث دون الحاجة إلى أي إجراء من المشغل.
- CVE-2025-68613 تغطي الإصدارات من 0.211.0 حتى ما دون 1.120.4: إذا لم تبلغ 1.120.4 بعد، فأنت معرض لثغرتين في آن.
- CVE-2026-21858 تؤثر في الإصدارات من 1.65.0 حتى ما دون 1.121.0: التحديث إلى 1.121.3 يعالج الثلاث دفعة واحدة.
- درجة EPSS 5.449% تضع هذه الثغرة في البيرسنتيل 92 من احتمالية الاستغلال الفعلي، مما يبرر إعطاءها الأولوية على سائر أعمال الصيانة المجدولة.
التحقق من إصدار نسخة n8n الخاصة بك
قبل تطبيق التحديث، حدد الإصدار الحالي بدقة. ثلاث طرق حسب سياق نشرك.
عبر واجهة الويب: سجّل الدخول إلى نسختك، انقر أيقونة الملف الشخصي في أسفل اليسار ثم "About n8n". يظهر الإصدار في النافذة المنبثقة.
عبر Docker: الأمر docker inspect <container-name> --format '{{index .Config.Labels "org.opencontainers.image.version"}}' يعيد إصدار الصورة الجارية. إذا بُدئ الحاوي من صورة n8nio/n8n:latest، تعكس هذه القيمة ما كان حالياً وقت آخر docker pull.
عبر واجهة API الداخلية: curl http://localhost:5678/healthz على الخادم المضيف يعيد {"status":"ok"} مع الإصدار في الترويسات إذا كانت النسخة تعمل.
إذا كان إصدارك دون 1.121.3، طبّق الإجراء أدناه دون انتظار نافذة الصيانة القادمة.
إجراء التحديث إلى n8n ≥ 1.121.3
نسخ احتياطي لقاعدة البيانات وملفات الإعداد
قبل أي تحديث، احتفظ بنسخة احتياطية من الحالة الحالية. لتثبيت Docker Compose، صدّر قاعدة بيانات SQLite أو PostgreSQL حسب إعدادك:
# SQLite (المسار الافتراضي) cp ~/.n8n/database.sqlite ~/.n8n/database.sqlite.bak-$(date +%Y%m%d) # PostgreSQL pg_dump -U n8n -d n8n > n8n-backup-$(date +%Y%m%d).sqlانسخ أيضاً ملف
docker-compose.ymlوملف.envإلى مسار احتياطي.تحديث ملف docker-compose.yml
إذا كنت تستخدم صورة
n8nio/n8n:latest، لا تعديل مطلوب على ملفdocker-compose.yml. إذا ثبّتَّ إصداراً محدداً (مثلn8nio/n8n:1.115.0)، حدّث سطرimage:services: n8n: image: n8nio/n8n:1.121.3لمتابعة الفرع الثابت طويل الأمد، يُفضَّل استخدام وسم إصدار صريح بدلاً من
latestللتحكم في نوافذ التحديث.سحب الصورة الجديدة
من المسار الذي يحتوي
docker-compose.yml:docker compose pullيُنزّل هذا الأمر الطبقات التي تغيرت فقط. على رابط بسرعة 100 ميجابت/ث، توقع من 30 إلى 90 ثانية حسب ذاكرة التخزين المؤقت المحلية.
إيقاف النسخة الحالية
docker compose downالإيقاف مُنظَّم: ينتظر n8n انتهاء التنفيذات الجارية قبل التوقف، ما لم تضف
--timeout 0. على نسخة مرتفعة الحمل، يُفضَّل انتظار إتمام سير العمل النشطة قبل تشغيل هذا الأمر، أو تعليق سير العمل الحرجة من الواجهة.إعادة التشغيل بالصورة الجديدة
docker compose up -dيستخدم Docker Compose الصورة المُنزَّلة حديثاً. يستغرق التشغيل عادةً 10 إلى 20 ثانية. يجب أن يُظهر سجل التشغيل الإصدار 1.121.3 أو أحدث.
التحقق من الإصدار المُنشَر
docker compose logs n8n | grep -i 'version\|n8n@'أو عبر API الداخلية من الخادم المضيف:
curl -s http://localhost:5678/healthzتأكد أن الإصدار المعروض في الواجهة (أيقونة الملف الشخصي ← About n8n) هو 1.121.3 أو أعلى قبل اعتبار التحديث مكتملاً.
تعطيل عقدة Git إذا لم تكن تستخدمها
لتحييد ناقل الهجوم فوراً دون انتظار التحديث (مثلاً إذا تعذرت نافذة الصيانة)، عطّل عقدة Git عبر متغير البيئة:
N8N_NODES_EXCLUDE='["n8n-nodes-base.git"]'أضف هذا المتغير إلى ملف
.envوأعد تشغيل النسخة. هذا ليس بديلاً عن التحديث: طبّق التحديث في أقرب وقت.لتثبيت npm (بدون Docker)
npm update -g n8n # أو عند استخدام مدير عمليات: pm2 stop n8n npm update -g n8n pm2 start n8nتحقق من الإصدار المثبت بـ
n8n --version. يُوصى بالانتقال إلى Docker للتثبيتات الجديدة — الدليل المخصصn8n-migration-npm-docker-avant-v3يغطي هذا المسار بالتفصيل.
التصليب بعد التحديث: تقليص سطح الهجوم
التحديث يصحح الثغرة المعروفة، لكن عدة إعدادات تعزز الوضع الأمني العام للنسخة.
قيّد صلاحيات عملية n8n. يجب ألا يعمل الحاوي بصلاحيات root. الصورة الرسمية تستخدم المستخدم node افتراضياً منذ عدة إصدارات — تحقق من أن docker-compose.yml لا يحتوي user: root.
فعّل المصادقة. إذا كانت نسختك مكشوفة على الإنترنت بلا مصادقة، أضف N8N_BASIC_AUTH_ACTIVE=true مع بيانات اعتماد قوية، أو ضع النسخة خلف وكيل يتطلب المصادقة. CVE-2026-21877 تستلزم مصادقة، لكن ناقلات غير مصادق عليها أخرى موجودة في البيئة.
قيّد العقد المسموح بها. متغير N8N_NODES_INCLUDE يتيح تفعيل مجموعة فرعية فقط من العقد. على النسخ المخصصة لسير عمل لا تحتاج Git أو وصولاً للنظام، تقليص القائمة يضيّق السطح.
راجع حسابات المستخدمين. في واجهة الإدارة، تحقق من مشروعية كل حساب نشط وتعطيل حسابات الاختبار وحسابات المتعاونين السابقين.
اشترك في تنبيهات أمان n8n. مستودع GitHub n8n-io/n8n يتيح الاشتراك في إشعارات الأمان عبر "Watch → Security alerts".
خطأ الجدولة بعد الإصدار 2.21.7: الأعراض والحل المؤقت
توثّق المسألة #31100 على GitHub سلوكاً أُبلغ عنه بعد التحديث إلى الإصدار 2.21.7: سير عمل ذات مشغّلات مجدولة (عقدة Schedule Trigger) تتوقف عن التنفيذ في موعدها دون أي رسالة خطأ في السجلات.
العرض الدقيق: تبقى سير العمل في حالة "نشطة" في الواجهة ويُعرض موعد المشغّل التالي، لكن التنفيذات لا تحدث. لا يُظهر سجل التنفيذات أي محاولة فاشلة — سير العمل ببساطة لا تُشغَّل. يُلاحَظ هذا السلوك أساساً في نشريات وضع الطابور (متعدد العمال) مع PostgreSQL، لكنه قد يؤثر في نسخ أحادية العملية أيضاً.
ما تشير إليه المسألة بشأن الحل المؤقت: وقت نشر هذا المقال، مُصنَّفة المسألة "Needs Feedback" من فريق n8n ولم يُنشر حل مؤقت رسمي موثق في الخيط. أفاد عدة مشغّلين بأن الإجراءات التالية أعادت التنفيذات المجدولة في بيئتهم:
- تعطيل ثم إعادة تفعيل كل سير عمل متأثرة يدوياً من الواجهة (مفتاح Active/Inactive).
- إعادة تشغيل حاوي n8n أو الخدمة لإعادة تهيئة طابور الجدولة الداخلي.
- في نشريات وضع الطابور: إعادة تشغيل العقدة الرئيسية (main) أولاً قبل العمال.
هذه الإجراءات ليست إصلاحاً: قد تتكرر المشكلة. تابع المسألة #31100 للاطلاع على الحالة الرسمية وإصدار الإصلاح.
تحديد سير العمل المتأثرة بسرعة: في واجهة n8n، صفّ سجل التنفيذات حسب مشغّل "Schedule" وابحث عن التنفيذات الغائبة في الفترة المتوقعة. سير عمل كان يفترض تشغيلها عشر مرات منذ منتصف الليل دون أي أثر في السجل هو إشارة واضحة.
التحققات بعد الترحيل: ما يجب مراجعته قبل إعادة فتح الحركة
تحديث n8n الناجح يُؤكَّد على عدة محاور، ليس فقط الإصدار المعروض.
الإصدار: تُظهر واجهة "About n8n" الإصدار 1.121.3 أو أعلى. أمر docker inspect على الصورة الجارية يعيد نفس الرقم.
سلامة بيانات الاعتماد: يشفّر n8n بيانات الاعتماد بمفتاح مشتق من N8N_ENCRYPTION_KEY. إذا لم يتغير هذا المتغير بين الإصدارين، بيانات الاعتماد الموجودة سليمة. افتح سير عمل يستخدم اتصالاً خارجياً وتحقق من تنفيذه دون أخطاء فك تشفير.
سير العمل النشطة: في لوحة التحكم، تحقق من أن عدد سير العمل النشطة يطابق الحالة قبل التحديث. سير عمل كانت نشطة وأصبحت غير نشطة بعد إعادة التشغيل إشارة تحذير.
التنفيذات المجدولة: إذا كانت نسختك تستخدم عقد Schedule Trigger، انتظر موعد التشغيل التالي وأكد التنفيذ في السجل. إذا كنت على الإصدار 2.21.7 من الفرع 2.x، راجع القسم السابق حول خطأ الجدولة.
سجلات التشغيل: docker compose logs n8n --tail 50 يجب أن يُظهر تشغيلاً نظيفاً بلا استثناءات. أخطاء الاتصال بقاعدة البيانات أو فك تشفير بيانات الاعتماد تظهر في هذه السطور الأولى.
الوصول الشبكي: إذا كانت نسختك مكشوفة عبر وكيل عكسي، تحقق من استجابة مسارات /webhook/ و/webhook-test/ بشكل صحيح بعد التحديث.
إصدارات n8n: التعرض لثغرات تنبيه AL26-001
مرّر الجدول أفقيًا
| الإصدار | CVE-2025-68613 | CVE-2026-21858 | CVE-2026-21877 | الإجراء المطلوب |
|---|---|---|---|---|
| < 1.120.4 | معرض | معرض | معرض | التحديث إلى ≥ 1.121.3 |
| 1.120.4 – 1.120.x | مُصلَح | معرض | معرض | التحديث إلى ≥ 1.121.3 |
| 1.121.0 – 1.121.2 | مُصلَح | مُصلَح | معرض | التحديث إلى ≥ 1.121.3 |
| ≥ 1.121.3 | مُصلَح | مُصلَح | مُصلَح | لا إجراء مطلوب للثغرات |
| 2.x < 2.21.7 | راجع ملاحظات الإصدار | راجع ملاحظات الإصدار | راجع ملاحظات الإصدار | راجع ملاحظات إصدار 2.x |
| 2.21.7+ | راجع ملاحظات الإصدار | راجع ملاحظات الإصدار | راجع ملاحظات الإصدار | خطأ الجدولة #31100 نشط |
الحفاظ على تحديث نسخة n8n: المسار على VPS
تكشف CVE-2026-21877 عن تكلفة نسخة مستضافة ذاتياً يعتمد تحديثها على نافذة صيانة خارجية. على VPS بوصول root، docker compose pull && docker compose up -d يطبّق التحديث في أقل من عشر دقائق دون الاعتماد على مزوّد لتحديد الموعد.
تأتي هذه الاستقلالية بمسؤولية: متابعة التنبيهات الأمنية تقع على المشغّل. مصدران لمتابعة n8n: مستودع GitHub (تبويب Security مع تفعيل الإشعارات) وتنبيهات المركز الكندي للأمن السيبراني أو ما يعادله من مراكز CERT في منطقتك.
للمزيد حول بناء نسخة n8n متينة — التثبيت الأولي ووكيل Caddy أو nginx العكسي وTLS التلقائي والنسخ الاحتياطي — راجع دليل تثبيت n8n على VPS. إذا كنت قادماً من تثبيت npm وتفكر في الانتقال إلى Docker قبل الانتقال إلى الفرع 2.x، يغطي دليل الانتقال من npm إلى Docker قبل v3 هذا المسار. نمط التحديث المطبق هنا مطابق للموثق في CVE-2026-6471 على PostgreSQL.
