تطبيقك يعمل، والطلبات تصل، ولوحة التحكم تفتح كالمعتاد. لهذا يسهل تأجيل تحديثات الأمان: البرنامج الذي يحتوي على ثغرة لا يتوقف بالضرورة عن العمل، ولا يرسل دائمًا تنبيهًا واضحًا.
في 11 نوفمبر 2026، نشر مشروع Node.js تحديثات أمنية للفروع 22 و24 و26. إذا كان موقعك يشغّل Node.js على الخادم، فالخطوة المفيدة الآن هي التحقق من المحرّك الذي يشغّل التطبيق فعلًا، وليس النسخة الموجودة على حاسوبك فقط.
ما الذي تغيّر؟
الإصدارات المنشورة هي Node.js 22.23.5 و24.22.3 و26.13.1. وتتضمن ملاحظاتها إصلاحات لمشكلات ذات خطورة عالية، خصوصًا في معالجة اتصالات HTTP/2 وTLS. ترتبط هذه الأجزاء باتصالات الشبكة والاتصالات المشفّرة، ويختلف التعرض للمخاطر بحسب طريقة تشغيل التطبيق.
المقصود هنا تحديث أمان لمحرّك Node.js، أي البرنامج الذي ينفّذ JavaScript على الخادم. ليس تحديثًا للمتصفح، ولا مجرد إصدار جديد من Express أو Next.js.
يمكن الرجوع إلى ملاحظات الإصدارات الرسمية: 22.23.5 و24.22.3 و26.13.1. تختلف الإصدارات المتأثرة وشروط الاستغلال من ثغرة إلى أخرى؛ وجود رقم رئيسي معيّن لا يعني أن التطبيق معرّض لجميع المشكلات المذكورة.
هل يستخدم موقعك Node.js فعلًا؟
بالنسبة إلى المطوّر، قد تبدو الإجابة بديهية. أما صاحب الموقع، فقد يرى اسم JavaScript فيظن أن كل شيء يعمل بالطريقة نفسها. الواقع أن وجود JavaScript في المشروع لا يعني بالضرورة تشغيل Node.js على الخادم الذي يستقبل الزوار.
| وضع مشروعك | ما الذي ينبغي التحقق منه؟ |
|---|---|
| واجهة API مبنية بـ Express أو تطبيق Next.js يعمل بخادم Node.js | نسخة المحرّك التي تشغّل التطبيق في بيئة الإنتاج |
| موقع React أو Vue مُصدَّر إلى ملفات ثابتة | بيئة البناء؛ ملفات HTML وCSS وJavaScript المنشورة لا تشغّل Node.js بمفردها |
| موقع WordPress تقليدي | PHP والإضافات أولًا، مع التحقق بشكل منفصل من أي أدوات Node.js مستخدمة حول الموقع |
| تطبيق يعمل داخل Docker | النسخة الموجودة في الصورة والحاويات المنشورة فعلًا |
| تطبيق يديره مطوّر أو مزوّد خدمة | تأكيد النسخة المستخدمة وإعادة تشغيل العمليات بعد التحديث |
قد يُبنى موقع تعريفي بـ React ثم يُنشر على شكل ملفات ثابتة. وفي المقابل، قد ينفّذ فضاء عملاء مبني بـ Next.js تعليمات على الخادم عند كل اتصال. لذلك لا يكفي اسم إطار العمل؛ السؤال هو: ما الذي يعمل فعلًا، وأين؟
وفي الجزائر كما في غيرها، العامل الحاسم هو الإعداد التقني. امتداد .dz أو الدفع بالدينار أو مكان الخادم لا يلغي الحاجة إلى تصحيح محرّك معرّض للخطر.
ما الإصدارات التي نتحقق منها في 13 نوفمبر 2026؟
يعرض الجدول الإصدارات الأصلية التي نشرها مشروع Node.js ضمن تحديثات 11 نوفمبر. هذه مرجعية مؤرّخة، وليست وعدًا بأن الأرقام ستبقى الأحدث لاحقًا.
| الفرع الذي يستخدمه تطبيقك | الإصدار التصحيحي المنشور في 11 نوفمبر |
|---|---|
| Node.js 22.x | 22.23.5 |
| Node.js 24.x | 24.22.3 |
| Node.js 26.x | 26.13.1 |
إذا توفّر إصدار أحدث من الفرع نفسه، اقرأ ملاحظاته قبل تحديد النسخة المستهدفة. وبعض توزيعات الأنظمة تدمج الإصلاحات في حزمها مع الاحتفاظ بترقيم مختلف؛ عندها تكون نشرة أمان الموزّع دليلًا مهمًا بدل الاعتماد على مقارنة الأرقام وحدها.
أما إذا كنت تستخدم فرعًا انتهى دعمه، فخطّط للانتقال إلى فرع مدعوم بعد التحقق من توافق التطبيق. توضّح الصفحة الرسمية إصدارات Node.js وحالة صيانتها.
الانتقال من 24.22.2 إلى 24.22.3 يختلف عن الانتقال من Node.js 22 إلى 26. الأول تحديث داخل الفرع نفسه، والثاني تغيير للإصدار الرئيسي. معالجة هذا الخبر لا تتطلب تغيير كل مكوّنات المشروع دفعة واحدة.
كيف تعرف النسخة الصحيحة في المكان الصحيح؟
من طرفية البيئة التي تستضيف التطبيق، يمكن عرض النسخة ومسار البرنامج المستخدم بالأمرين التاليين:
node --version
node -p "process.execPath"
لا يغيّر الأمران أي إعداد. لكنهما يصفان برنامج Node.js الذي استدعته هذه الطرفية تحديدًا. قد تستخدم خدمة النظام أو أداة إدارة العمليات أو الحاوية نسخة أخرى.
تخيّل أنك حدّثت Node.js في جلسة SSH، بينما يبدأ التطبيق من مسار ثابت في إعداداته. قد تعرض الطرفية النسخة الصحيحة، ويستمر الموقع في استخدام القديمة. وقد يُستبدل البرنامج على القرص دون إعادة تشغيل العملية التي بدأت قبل التحديث.
لتقليل هذا الالتباس، يمكن للمطوّر تسجيل النسخة عند بدء التطبيق داخل سجل خاص، مثلًا:
console.info('Node.js runtime:', process.version);
بعد النشر وإعادة التشغيل المنظّمة، تحقّق من السطر في سجل العملية الجديدة. لا تحتاج إلى صفحة تشخيص عامة، ولا إلى طباعة متغيرات البيئة؛ المطلوب رقم إصدار، لا كلمات مرور أو مفاتيح وصول. مرجع Node.js لخصائص process.
لماذا لا تكفي نتيجة npm audit؟
قد يقول مطوّر: «نفّذت فحص npm ولم يظهر شيء، إذن كل شيء محدّث». هنا اختلط فحصان مختلفان.
يفحص npm audit الثغرات المعروفة في حزم المشروع التي يعتمد عليها التطبيق. أما محرّك Node.js الذي ينفّذها فهو طبقة أخرى. نتيجة مطمئنة في فحص الحزم لا تثبت أن المحرّك يتضمن تصحيحات 11 نوفمبر.
والعكس صحيح أيضًا: تحديث Node.js لا يصلح تلقائيًا حزمة ضعيفة في Express أو Next.js أو غيرهما. احتفظ بالفحصين: نسخة المحرّك من جهة، وحزم التطبيق من جهة أخرى. تشرح وثائق npm audit ما يفحصه الأمر وتأثير خياراته.
تجنّب خصوصًا تشغيل npm audit fix --force في الإنتاج لمجرد إزالة التحذيرات. قد يؤدي هذا الخيار إلى تغييرات غير متوافقة، ولا يُعد بديلًا عن تحديث Node.js بشكل منظّم.
هل يحميني وجود وسيط أمام التطبيق؟
يستقبل الوسيط العكسي، أو reverse proxy، الطلبات قبل تمريرها إلى التطبيق. وقد تُعالَج اتصالات HTTPS أو HTTP/2 عند هذا المستوى بدلًا من معالجتها مباشرة داخل Node.js. هذا يغيّر التعرض لبعض الثغرات، لكنه لا يمنح ضمانًا عامًا.
يجب أيضًا النظر إلى الاتصالات التي يبدأها التطبيق نحو خدمات أخرى، والمكوّنات التي يستخدمها. اسأل المسؤول التقني أين تُعالَج البروتوكولات المعنية، ثم طبّق التصحيحات المناسبة. يناقش دليل أمان Node.js مخاطر شبكية وإجراءات دفاع مختلفة.
وقد تصادف في المنتديات أسماء Node2Shell أو HTTP2Shell أو Broccoli2Shell. استُخدمت هذه الأسماء حول تنبيه مرتبط بمكتبة Brotli في أكتوبر، وليست أسماء رسمية لمجموعة إصلاحات 11 نوفمبر كلها. لفهم ما يلزم تطبيقك اليوم، ارجع إلى التاريخ والمكوّن المعني والنشرة الرسمية. الاسم المتداول وحده لا يشرح إعداد خادمك.
تحديث الأمان دون تعطيل العمل
هذه الخطوات هي المسار الذي نقترحه لتطبيق صغير:
- حدّد البيئات المعنية. خادم الويب، والمهام الخلفية، وأدوات بناء الموقع قد تستخدم Node.js كلٌّ على حدة.
- اختر النسخة المناسبة داخل فرع مدعوم. تحقّق من متطلبات المشروع قبل اتخاذ قرار تغيير الإصدار الرئيسي.
- جهّز الاسترجاع. احتفظ بالإعدادات والبيانات اللازمة واعرف كيف تستعيد النشر السابق إذا فشل التحديث. الرجوع إلى نسخة ضعيفة لا ينبغي أن يتحول إلى حل دائم.
- جرّب في بيئة اختبار. افحص الدخول، والنماذج، ورفع الملفات، وواجهات API والوظائف المهمة لنشاطك.
- انشر وأعد تشغيل العمليات المعنية. تثبيت التصحيح واستخدامه فعلًا مرحلتان مختلفتان.
- راقب النتيجة. تحقّق من نسخة بدء التشغيل، والصفحات الأساسية، والأخطاء وإعادات التشغيل غير المعتادة، مع مقارنة ما قبل التحديث وما بعده.
إذا كنت تستخدم Docker، فتحديث Node.js على النظام المضيف لا يغيّر المحرّك داخل صورة موجودة. يلزم اختيار صورة مصحّحة، وإعادة بناء التطبيق عند الحاجة، ثم نشر حاويات جديدة. إعادة تشغيل الحاوية القديمة وحدها تُبقيها على صورتها السابقة. توضّح وثائق Docker الخاصة ببناء الصور وتجديدها هذه النقاط.
استضافة أم VPS: من يتولى التحقق؟
إذا كان مطوّر أو وكالة يدير التطبيق، يمكنك إرسال الرسالة التالية:
مرحبًا، هل يمكنكم التحقق من نسخة Node.js التي يستخدمها تطبيقنا فعليًا في الإنتاج، وتأكيد تطبيق تصحيحات 11 نوفمبر 2026، وفحص العمليات بعد إعادة تشغيلها؟ نرجو تزويدنا برقم النسخة وتاريخ التحقق.
على VPS تديره بنفسك، يتولى ذلك فريقك التقني أو الجهة التي تعاقدت معها للصيانة. وإذا كانت الاستضافة توفر لوحة لإدارة التطبيقات، فابدأ بإعدادات الموقع واطلب تأكيدًا إذا لم يظهر الإصدار التصحيحي بوضوح.
في SaharaCloud، يشرح دليل نشر تطبيق Node.js من GitHub المسار على عروض استضافة الويب المعنية. يساعدك الدليل على العثور على إعدادات التطبيق، لكنه لا يثبت أن موقعك يستخدم التصحيح بالفعل. لطلب التحقق، تواصل مع الدعم وحدّد الخدمة المعنية، دون إرسال كلمة مرور.
أسئلة يطرحها أصحاب المواقع
هل يجب الانتقال فورًا إلى Node.js 26؟
ليس بسبب هذا الإعلان وحده. إذا كان التطبيق يستخدم فرعًا ما زال مدعومًا، فابدأ بالتصحيح المتاح فيه. أما تغيير الإصدار الرئيسي فيحتاج إلى تحضير وفق احتياجات المشروع وتوافقه.
موقعي يعمل، هل يمكن تأجيل التحديث؟
عمل الموقع بشكل طبيعي لا يثبت خلوه من الثغرات. تحقّق سريعًا من النسخة والتعرض للمخاطر؛ الهدف من الاختبار تطبيق التصحيح بعناية، لا تأجيله بلا نهاية.
أستخدم WordPress، هل يعنيني الخبر؟
يعمل WordPress التقليدي بمحرك PHP. هذا الخبر يخص Node.js؛ تحقّق مما إذا كنت تستخدمه أيضًا لتطبيق منفصل أو لبناء ملفات الموقع. أما مقال ثغرات PHP في أكتوبر فيتناول خبرًا آخر.
هل يعني تثبيت التصحيح أن التطبيق أصبح آمنًا تمامًا؟
يصلح التحديث المشكلات التي يغطيها الإصدار. لكنه لا يثبت غياب ثغرات أخرى، ولا ينفي وقوع اختراق سابق. إذا لاحظت سلوكًا مريبًا، فاحتفظ بالسجلات واطلب فحص الحادث بشكل منفصل.
المصادر وتاريخ التحقق
أُعدّ المقال في 13 نوفمبر 2026. جرى التحقق من الأرقام والتواريخ في منشورات المشروع الرسمية، ويجب مراجعتها مجددًا عند تحديث المقال.
- Node.js: إصدارات 11 نوفمبر 22.23.5 و24.22.3 و26.13.1.
- Node.js: الإصدارات والصيانة، وممارسات الأمان، ووثائق process.
- npm: نطاق فحص npm audit وخياراته.
- Docker: بناء الصور وتحديثها.
ولفهم المفاهيم الأساسية بلغة أبسط، يمكنك متابعة دليلنا: الأمن السيبراني ببساطة.