تحديثات أمان Node.js لأكتوبر 2026: شو بتسكّر، وأي نسخة بعد 28 أكتوبر

إذا عندك خدمة <span dir="ltr">Node.js</span> شغّالة بالإنتاج، عندك اليوم قرارين: تحدّث هلق ولا تستنى، وعلى أي خط تثبّت مشاريعك للسنة الجاية. وبعد التحديث بيضل عليك تتأكد إنو الإنتاج عم يشغّل النسخة الجديدة، من جهازك لحد صورة <span dir="ltr">Docker</span>.

هل لازم تحدّث <span dir="ltr">Node.js</span> اليوم؟

إي. تحديثات <span dir="ltr">Node.js</span> يلي نزلت بـ 21 أكتوبر 2026 بتسكّر ثغرة خطورتها <span dir="ltr">High</span> على الأقل بكل خط مدعوم. صفحة الأمان بتعتبر الخطوط 22 و24 و26 متأثرة، والإصلاح بـ 22.23.4 و24.22.1 و26.12.1 أو أحدث بنفس الخط.

صفحة الأمان بتسمّي نسخة الإصلاح لكل خط، وملف schedule.json بمستودع فريق الإصدارات بيعطي مرحلة كل خط ونهاية دعمه. التواريخ الجاية فيه مخططة، والمستودع نفسه كاتب تحت جدوله «<span dir="ltr">Dates are subject to change</span>»:

إذا لسا على 20 أو 25، ما في نسخة إلك بهالتحديث. الـ 20 خلص دعمه بـ 30 أبريل 2026 والـ 25 بـ 1 يونيو 2026، والصفحة بتقول صريح: «<span dir="ltr">End-of-Life versions are always affected when a security release occurs</span>». يعني لازم تنقل لخط مدعوم.

لحتى تعرف وين إنت، شغّل هالأمر على جهازك وعلى كل سيرفر وجوّا كل حاوية، وقارن الرقم بالجدول:

node -v

شو الثغرات العشرة يلي بتسكّرها التحديثات؟

صفحة الأمان بتعدّ 10 ثغرات: 4 خطورتها <span dir="ltr">High</span>، و3 <span dir="ltr">Medium</span>، و3 <span dir="ltr">Low</span>. الخط 26 متأثر بالعشرة كلهم، والـ 24 بـ 8 منهم، والـ 22 بـ 7.

الصفحة وملاحظات الإصدار مش متفقين بنقطتين. الأولى: ملاحظات 26.12.1، ومتلها ملاحظات 24.22.1 و22.23.4، بتحط <span dir="ltr">CVE-2026-106072</span> بنفس سطر <span dir="ltr">CVE-2026-106069</span> وجنبهن <span dir="ltr">High</span>، والصفحة بتعطي 106072 خطورة <span dir="ltr">Medium</span>. خود الخطورة من الصفحة، لأنها إعلان الأمان نفسه. التانية: ملاحظات 26.12.1 ما بتذكر <span dir="ltr">CVE-2026-106071</span> بالرقم. فيها إصلاح بلا رقم اسمه «<span dir="ltr">src: fix the fs permission tree node on wildcard nodes</span>» من <span dir="ltr">James M Snell</span>، والصفحة بتشكر <span dir="ltr">jasnell</span> على إصلاح 106071، بس ولا مصدر بيربط الاتنين صريح.

ولحد 21 أكتوبر ما في سجل منشور لهالأرقام على <span dir="ltr">cve.org</span>، وصفحة الأمان بتعطي لكل ثغرة عنوانها وخطورتها والخطوط المتأثرة بس: ما فيها درجة <span dir="ltr">CVSS</span>، وما بتحدد من أي نسخة بلّشت كل ثغرة. فالمرجع يلي بإيدك هو نسخة الإصلاح لخطك، وأوضح شرح علني هو رسائل الـ <span dir="ltr">commits</span> يلي فيها الإصلاحات بمستودع <span dir="ltr">nodejs/node</span> على <span dir="ltr">GitHub</span>.

مع الثغرات، التحديث بيجدّد مكتبات جوّا <span dir="ltr">Node</span>: <span dir="ltr">c-ares</span> و<span dir="ltr">undici</span> على الخطوط التلاتة، و<span dir="ltr">OpenSSL</span> على 24 و22، و<span dir="ltr">SQLite</span> على 22. وفيه كمان تحديث لشهادات الـ <span dir="ltr">CA</span> المدمجة، والصفحة بتربطه بـ «<span dir="ltr">eMudhra Intermediate CA Compromise</span>».

شو يعني خلل <span dir="ltr">Brotli</span> وكيف بيوصل لخدمتك؟

ثغرة <span dir="ltr">Brotli</span> (<span dir="ltr">CVE-2026-111497</span>) خلل بفك الضغط بيكتب برّا حدود الذاكرة، وهي الوحيدة بالقائمة يلي عنوانها بيقول «تنفيذ كود عن بعد». بتخصك إذا خدمتك بتفك ضغط <span dir="ltr">Brotli</span> لبيانات جاية من برّا، وهي على الخطوط التلاتة.

الـ <span dir="ltr">Brotli</span> صيغة ضغط بلا خسارة موصوفة بـ <span dir="ltr">RFC 7932</span>، وهي يلي بتشوفها بالـ <span dir="ltr">HTTP</span> كـ Content-Encoding: br. بـ <span dir="ltr">Node</span>، فك الضغط بيشتغل لما تستدعي zlib.brotliDecompress() أو zlib.createBrotliDecompress().

وfetch المدمج كمان بيفك <span dir="ltr">Brotli</span> عنك. بكود <span dir="ltr">undici</span> جوّا <span dir="ltr">Node 24.22.1</span>، أي طلب لعنوان https بياخد ترويسة accept-encoding: br, gzip, deflate إذا ما حطيت إنت وحدة. وإذا السيرفر رجّع الرد مع Content-Encoding: br، الـ fetch بيفكه بـ zlib.createBrotliDecompress. يعني خدمة بتجيب بيانات من <span dir="ltr">API</span> برّا بـ fetch ممكن تكون عم تفك <span dir="ltr">Brotli</span> حتى لو ما كتبت ولا سطر ضغط: السيرفر يلي عم تحكي معه هو يلي بيختار يرجّع br.

الصفحة ما نشرت كيف بتنضرب الثغرة، وما عطت حل مؤقت. الإصلاح نفسه جاي من مكتبة <span dir="ltr">Brotli</span>: <span dir="ltr">Node</span> نقل <span dir="ltr">commit</span> من <span dir="ltr">google/brotli</span> عنوانه «<span dir="ltr">Detect and report invalid stream earlier</span>»، على ملف فك الضغط c/dec/decode.c. وما في إصلاح معلن غير التحديث.

شو يعني تخطّي فحص اسم المضيف بـ <span dir="ltr">TLS</span>؟

فحص اسم المضيف هو الخطوة يلي بيتأكد فيها <span dir="ltr">Node</span> إنو شهادة السيرفر صادرة للاسم أو الـ <span dir="ltr">IP</span> يلي طلبته. تلات ثغرات بهالتحديث بتخلي هالفحص يمرق غلط لما الـ <span dir="ltr">IP</span> مكتوب بشكل غير الشكل المعتاد.

بتوثيق <span dir="ltr">Node</span>، الفحص اسمه tls.checkServerIdentity()، وهو بيتأكد إنو الشهادة صادرة للـ hostname يلي عم تتصل فيه. الثغرات التلاتة:

• <span dir="ltr">CVE-2026-105483</span> (<span dir="ltr">High</span>، على 26 و24): الـ <span dir="ltr">IP</span> مكتوب بأرقام عريضة، يعني محارف متل «１» بدل «1».

• <span dir="ltr">CVE-2026-106069</span> (<span dir="ltr">High</span>، على الخطوط التلاتة): المضيف بيتحوّل لعنوان <span dir="ltr">IP</span> بتساهل.

• <span dir="ltr">CVE-2026-106072</span> (<span dir="ltr">Medium</span> حسب الصفحة، على الخطوط التلاتة): عنوان <span dir="ltr">IPv4</span> مكتوب بشكل غير قياسي بيخلي شهادة صادرة لاسم دومين تمرق لعنوان <span dir="ltr">IP</span>.

نفس العنوان بينكتب بأكتر من شكل، وفي شكل بينقرا كعنوان تاني. جرّب هالكود، وشوف شو بيرجّع الـ <span dir="ltr">URL parser</span> لكل شكل:

for (const host of ['127.1', '0x7f.0.0.1', '１２７.０.０.１', '0127.0.0.1']) {
  console.log(host, '->', new URL('https://' + host + '/').hostname);
}
// 127.1 -> 127.0.0.1
// 0x7f.0.0.1 -> 127.0.0.1
// １２７.０.０.１ -> 127.0.0.1
// 0127.0.0.1 -> 87.0.0.1

آخر سطر طلع 87.0.0.1، لأنو الـ <span dir="ltr">URL parser</span> بيقرا الرقم يلي بيبلّش بصفر بالنظام التماني (<span dir="ltr">octal</span>)، حسب معيار الـ <span dir="ltr">URL</span>.

رسالة <span dir="ltr">commit</span> الإصلاح بتشرح المشكلة: فحص الهوية بـ <span dir="ltr">TLS</span> كان يوحّد شكل العنوان الرقمي قبل ما يقارنه بالشهادة، والـ <span dir="ltr">resolver</span> تبع نظام التشغيل ممكن يقرا النص الأصلي كعنوان تاني. يعني الشهادة بتنفحص على عنوان، والاتصال ممكن يروح لعنوان غيره.

إصلاح 106069 و106072 اسمه «<span dir="ltr">tls: reject non-canonical IP addresses</span>»، وإصلاح 105483 لحاله اسمه «<span dir="ltr">tls: fix ip normalization regression</span>». بعد التحديث، tls.checkServerIdentity() بيرفض أي مضيف ما بيصير عنوان <span dir="ltr">IP</span> إلا بعد ما يتوحّد شكله، وبيرجّع الخطأ ERR_TLS_CERT_ALTNAME_INVALID مع السبب «<span dir="ltr">Host is a non-canonical IP address</span>». واختبار الـ <span dir="ltr">commit</span> نفسه بيتصل على 0127.0.0.1 وبيستنى هالخطأ.

فإذا عندك خدمة بتاخد اسم المضيف كنص، من الإعدادات أو من المستخدم، وبتتصل عليه بـ <span dir="ltr">TLS</span>، دوّر على عناوين رقمية مكتوبة بشكل مختصر أو بصفر بالأول. على النسخ الجديدة هالاتصال بيفشل بهالخطأ، فجرّبها قبل الإنتاج واكتب العنوان بشكله العادي، متل 127.0.0.1.

ليش <span dir="ltr">randomUUID</span> بيكرر نفس القيم بالـ <span dir="ltr">snapshots</span> والـ <span dir="ltr">SEA</span>؟

<span dir="ltr">Node</span> بيحضّر دفعة بيانات عشوائية سلف لـ randomUUID() وrandomInt() لحتى يسرّعهن. الثغرة <span dir="ltr">CVE-2026-106074</span> إنو هالدفعة كانت تنحفظ جوّا الـ <span dir="ltr">startup snapshot</span> أو الـ <span dir="ltr">SEA</span>، فكل <span dir="ltr">process</span> بيبلّش منهن بيطلّع نفس القيم.

توثيق crypto.randomUUID() بيقول إنو <span dir="ltr">Node</span> بالوضع الافتراضي «<span dir="ltr">generates and caches enough random data to generate up to 128 random UUIDs</span>». الـ <span dir="ltr">startup snapshot</span> ملف بيحفظ حالة تطبيقك بعد التهيئة وبيرجع يحمّلها لما يبلّش، وبينعمل بـ --build-snapshot. والـ <span dir="ltr">SEA</span> (<span dir="ltr">Single Executable Application</span>) نسخة من ملف node التنفيذي محقون فيها سكربتك، فبيطلع عندك ملف واحد بتوزّعه.

إذا ما بتستعمل ولا وحدة منهن، هالثغرة ما بتخصك. وإذا بتستعملهن وعم تولّد بـ randomUUID() قيمة لازم ما حدا يحزرها، متل رمز جلسة أو رابط تغيير كلمة سر، فهاد أول شي بتصلّحه.

هون التحديث لحاله ما بيكفي. <span dir="ltr">commit</span> الإصلاح بيفضّي هالكاش قبل ما ينحفظ الـ <span dir="ltr">snapshot</span> وبعد ما يرجع ينحمّل، بس الملف يلي بنيته قبل التحديث بيضل متل ما هو. الـ <span dir="ltr">SEA</span> جوّاه نسخة node يلي بنيته فيها، فلازم تبنيه من جديد بالنسخة الجديدة (توثيق الـ <span dir="ltr">SEA</span>). والـ <span dir="ltr">snapshot</span> كمان بينبني من جديد: حسب توثيق --snapshot-blob، <span dir="ltr">Node</span> بيرفض يحمّل <span dir="ltr">snapshot</span> انبنى بنسخة تانية وبيطلع بـ <span dir="ltr">exit code</span> 1.

على أي خط بتثبّت مشاريعك السنة الجاية؟

على الـ 26. حسب schedule.json، الخط 26 بيصير <span dir="ltr">LTS</span> بـ 28 أكتوبر 2026 وبيضل مدعوم لـ 30 أبريل 2029، وهاد أطول دعم بين الخطوط المتاحة اليوم. الـ 24 بيضل ياخد تحديثات أمان لـ 30 أبريل 2028، بس بمرحلة <span dir="ltr">Maintenance</span>.

• الخط 24 دخل <span dir="ltr">Maintenance</span> بـ 20 أكتوبر 2026. هالمرحلة حسب <span dir="ltr">README</span> المستودع «<span dir="ltr">Critical bug fixes and security updates</span>»، والميزة الجديدة فيها استثناء بيقرره فريق الإصدارات، غالباً لما بتساعد بالنقل لخط أحدث. جدول الـ <span dir="ltr">README</span> لسا كاتبه <span dir="ltr">Active LTS</span> بـ 21 أكتوبر، بس التاريخ بالملف 20 أكتوبر.

• الخط 22 بيخلص بـ 30 أبريل 2027، وبعدها ما في تحديثات أمان. إذا عندك مشروع عليه، حط النقلة بخطة الأشهر الجاية.

• اسم الخط 26 الرمزي (<span dir="ltr">codename</span>) لسا فاضي بالملف، فاكتب الرقم 26 بملفاتك بدل أي اسم.

• أول نسخ الخط 27 بتطلع بـ 28 أكتوبر بمرحلة <span dir="ltr">Alpha</span>، وهي حسب الـ <span dir="ltr">README</span> «<span dir="ltr">not for production use</span>». بيصير <span dir="ltr">Current</span> بـ 22 أبريل 2027 و<span dir="ltr">LTS</span> بـ 20 أكتوبر 2027.

ومن الـ 27 وطالع، المشروع بيطلّع إصدار رئيسي واحد بالسنة، وكل خط بيصير <span dir="ltr">LTS</span> (إعلان تغيير جدول الإصدارات، 10 مارس 2026). وحسب نفس الـ <span dir="ltr">README</span>، هالخطوط بتضل <span dir="ltr">Active LTS</span> طول الـ 30 شهر وما بتمرق بمرحلة <span dir="ltr">Maintenance</span>. وإذا عم تتعلم <span dir="ltr">Node</span> هلق من الصفر، ابدأ على 26 مباشرة، ورتّب باقي طريقك مع خارطة طريق المبرمج 2026.

من وين تبلّش التحديث هلق؟

بلّش من الإنتاج: شوف شو عم يشغّل فعلاً، بعدين ثبّت الرقم بالمشروع والـ <span dir="ltr">CI</span>، وآخر شي ابني صور <span dir="ltr">Docker</span> من جديد. الصورة يلي انبنت قبل التحديث بتضل على النسخة القديمة لحد ما تبنيها.

1. شغّل node -v على كل سيرفر وجوّا كل حاوية. لازم يطلع 22.23.4 أو 24.22.1 أو 26.12.1، أو أحدث بنفس الخط.

2. حدّث ملف .nvmrc بالرقم الجديد. حسب <span dir="ltr">README</span> تبع <span dir="ltr">nvm</span>، nvm install وnvm use بيقروا النسخة من هالملف إذا ما كتبت وحدة:

    echo "24.22.1" > .nvmrc
    nvm install
    node -v

3. اكتب الحد الأدنى بحقل engines بـ package.json. انتبه إنو >=24.22.1 لحاله بيقبل 26.0.0، وهي أقدم من نسخة الإصلاح على الخط 26، فاكتب كل خط لحاله:

    {
      "engines": {
        "node": "^22.23.4 || ^24.22.1 || >=26.12.1"
      }
    }

   حسب توثيق <span dir="ltr">npm</span>، بلا engine-strict هالحقل «<span dir="ltr">advisory only</span>»، وبيطلّع تحذيرات لما حزمتك تنزل كـ <span dir="ltr">dependency</span>. فإذا بدك <span dir="ltr">npm</span> يوقف التثبيت بمشروعك على نسخة برّا المدى، زيد هالسطر على .npmrc بالمشروع. معه، npm install بيطلع بخطأ EBADENGINE بدل التحذير (توثيق engine-strict):

4. خلّي الـ <span dir="ltr">CI</span> يجيب آخر نسخة. actions/setup-node بالوضع الافتراضي (check-latest: false) بيستعمل النسخة المخزّنة على الـ <span dir="ltr">runner</span> إذا بتطابق (التوثيق)، فممكن يضل على نسخة أقدم من الإصلاح:

    strategy:
      matrix:
        node-version: [22.x, 24.x, 26.x]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node-version }}
          check-latest: true
      - run: node -v
      - run: npm ci
      - run: npm test

5. ابني صور <span dir="ltr">Docker</span> من جديد بـ --pull وانشرها. على <span dir="ltr">amd64</span> و<span dir="ltr">arm64</span>، الوسوم 22 و24 و26 على <span dir="ltr">Docker Hub</span> صارت تأشّر على النسخ الجديدة بـ 21 أكتوبر، وباقي المعماريات بتنضاف لما يخلص بناءها: حسب <span dir="ltr">README</span> الصور الرسمية، البناء ممكن ياخد ساعات. و--pull (توثيق <span dir="ltr">Docker</span>) بيخلي البناء يسحب الصورة الأحدث بدل النسخة المخزّنة عندك، وnode -v جوّا الصورة بيأكدلك شو طلع:

    docker build --pull -t my-api .
    docker run --rm my-api node -v

   وانتبه لـ node:lts: حسب نفس الـ <span dir="ltr">README</span> هو نسخة الـ <span dir="ltr">Active LTS</span>. هلق بيأشّر على 24.22.1: الـ 24 صار <span dir="ltr">Maintenance</span>، بس الـ 26 لسا ما صار <span dir="ltr">LTS</span>. لما يصير الـ 26 <span dir="ltr">LTS</span> بـ 28 أكتوبر حسب الجدول، المتوقع ينتقل الوسم معه، فإذا ما بدك تنقل خط كامل بلا ما تنتبه، اكتب الرقم بـ FROM، متل node:24.22.1-bookworm-slim.

6. شغّل الاختبارات قبل الإنتاج، خصوصاً على 26: ملاحظات 26.12.1 فيها تراجع عن تغيير بتحميل الـ <span dir="ltr">ES modules</span> («<span dir="ltr">Revert "module: synchronously load most ES modules"</span>»).

التحديث بيسكّر ثغرات <span dir="ltr">Node</span> نفسه، وثغرات الصلاحيات بكودك إنت بتضل متل ما هي. لهالشغل عم جهّز حزمة المهارات الأمنية، ولسا قيد التحضير: مهارات بتراجع كود مشروعك وبتنبّهك لثغرات <span dir="ltr">IDOR</span> والصلاحيات قبل النشر. وإذا بدك حدا يجرّب منصتك متل ما بيجرّبها مهاجم، فحص الاختراق بمُحَصَّن بيفحص بطبقة الويب والـ <span dir="ltr">API</span> إذا الجلسات بتنسرق أو بتنزوّر، وإذا مستخدم بيقدر يوصل لبيانات مستخدم تاني.

شو أقدم نسخة <span dir="ltr">Node</span> عم تشتغل عندك بالإنتاج هلق؟