كل المقالات

⁨Node.js⁩: تكرار ⁨randomUUID()⁩ في اللقطات وحدود نموذج الصلاحيات

⁨Node.js⁩ · 3 دقيقة قراءة ·

معظم الاهتمام في تحديث أمان ⁨Node.js⁩ لشهر أكتوبر 2026 يذهب إلى الثغرات عالية الخطورة. لكن إصلاحين أصغر يستحقان وقفة مستقلة، لأنهما يصحّحان افتراضين نعتمدهما دون تفكير: أن ⁨crypto.randomUUID()⁩ يعطي كل عملية قيمة مختلفة، وأن نموذج الصلاحيات جدار. في أغلب التطبيقات لا يغيّر أي منهما شيئًا، لكنهما يهمّان فئتين محددتين من المطورين.

حين يكون "العشوائي" واحدًا في كل العمليات

الثغرة ⁨CVE-2026-106074⁩، المتوسطة الخطورة والمصلَحة على الخطوط ⁨26⁩ و⁨24⁩ و⁨22⁩، تخص لقطات بدء التشغيل والتطبيقات التنفيذية الأحادية (⁨SEA⁩). ذاكرة الإنتروبيا المؤقتة خلف ⁨crypto.randomUUID()⁩ و⁨randomInt()⁩ كانت تُحفظ داخل اللقطة أو الملف التنفيذي، فتكرر كل عملية تبدأ منه القيم نفسها.

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

تُلتقط مرة وقت البناء اللقطة أو الملف الأحادي عشوائية مخزّنة العملية 1: القيمة أ العملية 2: القيمة أ العملية 3: القيمة أ ثلاث عمليات وقيمة "عشوائية" واحدة
استعادة الحالة الملتقطة هي فكرة اللقطة أصلًا. قبل الإصلاح كانت تستعيد العشوائية معها.

من يتأثر: من يبني لقطة بدء تشغيل خاصة أو يوزّع ملفًا تنفيذيًا أحاديًا ويولّد فيه معرّفات أو رموزًا أو مفاتيح بهاتين الدالتين. من لا يتأثر: التطبيق العادي الذي يعمل بالأمر ⁨node server.js⁩، وهكذا تعمل معظم تطبيقات ⁨Node⁩.

والدرس أبقى من الإصلاح، كممارسة عامة: لا تشتق معرّفات أو رموزًا أو أسرارًا من قيم أُنشئت وقت البناء، بل أنشئها بعد أن تبدأ العملية. وإن كنت توزّع ملفًا أحاديًا أو لقطة، فالفحص السريع أن تطبع قيمة واحدة عند البدء، وتشغّل الملف مرتين، وتقارن:

// run at startup, start the executable twice, compare the output
console.log('boot id', crypto.randomUUID());

سطران مختلفان يعنيان أن لكل عملية عشوائيتها. سطران متطابقان يعنيان أن بيئة التشغيل غير مرقّاة، أو أن شيئًا ما يُلتقط مبكرًا أكثر مما ينبغي.

نموذج الصلاحيات طبقة، لا جدار

يسمح نموذج الصلاحيات في ⁨Node.js⁩ للعملية بتقييد وصولها إلى نظام الملفات والشبكة وما شابه. يصلح هذا التحديث ثغرتين فيه، كلتاهما منخفضة الخطورة: ⁨CVE-2026-106073⁩، تجاوز عبر ⁨fs.realpathSync⁩ على الخطوط ⁨26⁩ و⁨24⁩ و⁨22⁩، و⁨CVE-2026-106071⁩، منح صلاحيات ملفات أوسع من المطلوب عبر بحث بالمحارف البديلة على الخط ⁨26⁩ وحده. وإصلاح ثالث منخفض، ⁨CVE-2026-106070⁩ على ⁨26⁩ وحده، يمنع ⁨ZipFile⁩ من إعادة بايتات بادئة يتحكم فيها المهاجم بعد فشل التحقق من ترويسة الملف المضغوط.

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

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

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

أنشئ المعرّفات والأسرار بعد بدء العملية لا وقت البناء، واجعل نظام التشغيل، لا بيئة التشغيل، هو الحد حول الكود غير الموثوق.

الخطوة التالية هي الترقية نفسها المطلوبة لبقية التحديث: ⁨26.12.1⁩ أو ⁨24.22.1⁩ أو ⁨22.23.4⁩ حسب خطك. وإن كنت توزّع ملفًا أحاديًا أو لقطة، فأعد فحص التشغيل المزدوج بعد الترقية. المصدر: صفحة تحديثات الأمان على ⁨nodejs.org⁩ بتاريخ 21 أكتوبر 2026.

ملاحظات القراء

  1. لا توجد ملاحظات بعد. الأولى دائمًا الأجرأ.
باغي تبني شي حاجة بحال هادي؟ نقدر نعاونك. راسلني على واتساب