تحديث Node.js الأمني في أكتوبر 2026: حدّث وتحقق من كل Fleet

أصدر مشروع Node.js تحديثات أمنية للخطوط النشطة 22 و24 و26 في 21 أكتوبر 2026. تعالج الإصدارات أربع ثغرات High، بينها Out-of-bounds Write في Brotli Decoder قد يفسد ذاكرة العملية، إضافة إلى اختلافات خطرة في التحقق من أسماء DNS وTLS. يجب على فرق الإنتاج التحديث إلى Node.js 22.23.4 أو 24.22.1 أو 26.12.1، وإعادة بناء الصور وSnapshots، واستبدال جميع العمليات، والتحقق من Runtime الذي يخدم الترافيك فعليًا. تحديث حزم التطبيق وحده لا يصلح هذه الثغرات داخل Runtime.

يفصل هذا المقال بين حقائق Node.js الرسمية والتوصيات الهندسية. أوصاف الثغرات والخطوط المتأثرة والإصدارات المصححة مأخوذة من Advisory الرسمي المنشور والمحدّث في 21 أكتوبر 2026. أما خطة النشر والرصد والضوابط المعمارية فهي إرشادات دفاعية. لا ندعي وجود استغلال عام إلا إذا ذكره المصدر الأولي.

ماذا يتضمن الإصدار الأمني؟

يسرد مشروع Node.js عشر مشكلات في Runtime، إلى جانب تحديثات c-ares وشهادات CA وOpenSSL وSQLite وUndici. أعلى شدة هي High.

الإصدارات النشطة المصححة هي:

• Node.js 22.23.4؛
• Node.js 24.22.1؛
• Node.js 26.12.1.

الفروع End-of-Life لا توفر الضمان نفسه. انتقل إلى خط مدعوم ومصحح، أو احصل على توثيق Vendor Backport يغطي CVEs المعنية. استمرار الخدمة في العمل لا يثبت أمان Runtime.

لماذا تحصل ثغرة Brotli على الأولوية؟

CVE-2026-111497 تقع في Brotli Decoder المدمج مع Node.js. يوضح Advisory أن Block Switch غير صالح عومل كحاجة مؤقتة لمزيد من المدخلات بدل Format Error دائم. عند Streaming Decompression قد تُضاف Bytes لاحقة بعد حدود Buffer داخلي حجمه ثمانية Bytes.

يحتاج المهاجم إلى تمرير بيانات Brotli يفكها التطبيق عبر node:zlib. وقد تشمل النتيجة Crash أو كشف ذاكرة العملية أو Remote Code Execution. هذا لا يعني أن كل خدمة HTTP مبنية بـNode.js قابلة للاستغلال عن بعد؛ الوصول يعتمد على وجود مسار ينقل بيانات مضغوطة غير موثوقة إلى Decoder. لكنه يجعل مسارات Upload وArchive وMessaging وProxy وTransformation ذات أولوية عالية.

ابحث عن الاستخدام المباشر والمغلف لـBrotli:

rg -n "brotli|createBrotliDecompress|BrotliDecompress|zlib" src app packages

وافحص Dependencies وWorkers المنفصلة التي تفك Blobs مصدرها العميل. Source Search وحده لا يكفي عندما تكون العملية داخل Native Addon أو Queue Worker أو Media Service.

لا ترسل Exploit Files إلى الإنتاج لإثبات الوصول. تحقق من المسار باستخدام Fixtures آمنة وTracing واختبارات Staging، ثم حدّث.

NUL في DNS يكسر تصميم Validate ثم Resolve

تؤثر CVE-2026-105482 في dns.resolve*() وdns.reverse(). قد يتحقق التطبيق من اسم مثل attacker.example\0.trusted.example كنص كامل، ثم يُقتطع عند تمريره كـC String إلى c-ares، فتذهب Query إلى attacker.example.

يهم ذلك دفاعات SSRF وWebhooks وIntegration Hosts التي يحددها Tenant وAllowlist للاتصالات الخارجية. النمط الخطر هو:

1. التحقق من Host الأصلي مقابل Allowlist؛
2. حله لاحقًا بدالة Runtime؛
3. الاتصال بالعنوان الناتج مع افتراض أن المرحلتين استخدمتا الهوية نفسها.

حدث Runtime أولًا. وللدفاع الإضافي ارفض NUL وControl Characters، واستخدم Parser واحدًا وCanonicalization واحدة، واربط Host المتحقق منه بسياسة الاتصال. وأعد فحص IP الناتج مقابل Private وLoopback وLink-local وMetadata Ranges إذا كان المنتج يقبل وجهات خارجية.

يجب أن يتفق TLS مع Parsing الاتصال

هناك ثلاث مشكلات مرتبطة بصياغة IP غير المعيارية:

• CVE-2026-105483: قد تعامل Fullwidth Digits كاسم DNS عند مطابقة الشهادة رغم أن Resolution يصل إلى IPv4؛
• CVE-2026-106069: قد يفسر WHATWG الصفر البادئ كـOctal بينما يعامله OS Resolver كـDecimal؛
• CVE-2026-106072: صيغ Hex أوInteger واحد أو IPv4 مختصر قد تسمح بمطابقة DNS SAN بدل IP Address SAN.

الحد الأمني هنا هو اتفاق الهوية: Parsing وResolution وConnection وCertificate Verification يجب أن تشير كلها إلى Endpoint معيارية واحدة.

بالنسبة إلى Upstreams يحددها المستخدم، ارفض الصيغ الملتبسة بدل دعم كل صيغة تاريخية. حلل URL، واجعل Host معيارية، واستخدم net.isIP() للـIP Literals، واطلب النص القياسي، وطبق سياسة الشهادة على القيمة نفسها المستخدمة في الاتصال. ولا تستبدل checkServerIdentity بـCallback يعيد النجاح دائمًا.

Keep-alive وهوية Response

تؤثر CVE-2026-105481 في إعادة استخدام اتصال HTTP Agent. قد تصل Response غير مطلوبة إلى Socket خامل قبل إرسال طلب جديد. وإذا كان Event Loop مشغولًا، قد يزال Guard عند تسليم Socket للطلب، فتفسر البيانات القديمة كاستجابة للطلب الجديد.

التحديث هو العلاج الأساسي. تشغيليًا، لا تختصر هوية الاستجابة في Status Code. في APIs الداخلية الحساسة استخدم Correlation أوSigned Responses أوIdempotency على مستوى التطبيق عند الحاجة. وانقل العمل المتزامن الثقيل بعيدًا عن Main Event Loop؛ Event-loop Starvation خطر توافر أيضًا، لكنه ليس بديلًا عن التحديث.

أعد بناء Snapshots وSingle Executable Applications

تؤثر CVE-2026-106074 في Entropy Caches المستخدمة بواسطة crypto.randomUUID() وcrypto.randomUUIDv7() وcrypto.randomInt() عندما تمتلئ أثناء بناء User-land Startup Snapshot أوSingle Executable Application يستخدم useSnapshot. قد تكرر كل عملية تبدأ من Artifact القيم المخبأة حتى تمتلئ Cache من جديد.

يعطي Advisory حدًا يصل إلى 127 UUID مكررًا ونحو 1,000 قيمة randomInt(). قد تكسر التصادمات افتراضات Unique، وقد تصبح القيم قابلة للتنبؤ بمراقبة عملية أخرى.

تحديث Node Binary وقت التشغيل لا يكفي إذا كان Artifact يتضمن Snapshot أنشأها Builder ضعيف. أعد بناء Snapshots وSEA باستخدام Runtime المصحح، وانشر Digest جديدة، وراجع هل يستدعي Build للـSnapshot وظائف UUID أوRandom.

لا تستخدم UUID أوRandom Integer كـAuthentication Secret لمجرد أنها غالبًا فريدة. تحتاج Tokens إلى تصميم Cryptographic واضح وEntropy مناسبة.

إصلاح Permission Model لا يلغي Sandbox النظام

قد تمنح CVE-2026-106071 مسارًا أقصر بسبب طريقة Wildcard في Radix Tree. وتترك CVE-2026-106073 وظيفة fs.realpathSync() قادرة على كشف وجود الملفات وأهداف Symlink خارج نطاق القراءة المسموح.

حدّث حتى إذا كان Permission Model مجرد Defense in Depth، ثم أعد اختبار Flags الإنتاج الفعلية. واحتفظ بضوابط OS مثل Container User وRead-only Filesystem وMount Boundaries وseccomp وMandatory Access Control؛ طبقة صلاحيات لغة ليست Sandbox كاملًا للكود العدائي.

خطة تحديث Hosts وContainers وServerless

استخدم Workflow استبدال بدل تعديل Machine واحدة:

1. Inventory: سجل الخدمة والبيئة وخط Runtime والإصدار الكامل وImage/Artifact Digest وBuild Pipeline، وهل تستخدم Brotli أوCustom TLS أوDNS Allowlist أوSnapshots أوSEA أوPermission Model.
2. اختر الإصدار المصحح: انتقل إلى 22.23.4 أو24.22.1 أو26.12.1. إذا قدم Platform Backport فاطلب Advisory يغطي CVEs.
3. Rebuild: أعد بناء Base Images وApplication Images وNative Addons وSnapshots وSEA من مصادر موثوقة. لا تنسخ Node Binary ضعيفة من Build Stage قديمة.
4. Canary: اختبر DNS/TLS Clients والمدخلات المضغوطة وProxies وUploads وQueues وتفرد UUID وCold Starts وصلاحيات الملفات.
5. Replace: انشر Artifacts ثابتة، واسحب Workers القديمة، وأعد تشغيل Process Managers. تحتاج Serverless إلى Artifact أوRuntime Selection جديدة.
6. Verify: اقرأ نسخة Runtime من كل Replica تخدم الترافيك، وتأكد أن Autoscaling Templates تستخدم Digest الجديدة.
7. Monitor: راقب Crashes وأخطاء Decompression وفشل TLS/DNS وDuplicate Identifiers وPermission Denials غير المتوقعة.

console.log({
  node: process.version,
  release: process.release,
  platform: process.platform,
  arch: process.arch,
});

يثبت هذا Output العملية التي وصلت إليها فقط. في Fleet خلف Load Balancer، عدد كل Instance عبر Operations Telemetry موثقة. واحذف Diagnostics المؤقتة بعد التحقق.

مثال تحقق للـContainer

اختبر الصورة نفسها المستخدمة في الإنتاج:

docker run --rm --entrypoint node your-registry/app@sha256:IMAGE_DIGEST   -p "process.version + ' ' + process.versions.openssl"

ثم تأكد أن Orchestrator لم يعد يشغل Digests قديمة. يمكن تحريك Tags ولذلك هي دليل ضعيف؛ سجل Digest الثابتة في Deployment وAudit.

في Kubernetes حدث Image، واستخدم Rolling Deployment مضبوطًا، وراقب Readiness وError Budgets، ثم اقرأ Pod Image IDs بعد اكتمال Rollout. نجاح Build لا يثبت اختفاء Pods أوJobs أوAutoscaling Templates القديمة.

التحقيق دون ادعاء اختراق

يصف Advisory آلية الثغرات، لكنه لا يقول إن كل خدمة متأثرة استُغلت. افصل ثلاث حالات:

• Vulnerable: وُجد Runtime متأثر ومسار قابل للوصول؛
• Attempted Exploitation: تظهر Logs مدخلات مصممة متوافقة مع المسار؛
• Confirmed Compromise: توجد أدلة Process أوHost أوBusiness على أثر غير مصرح.

بالنسبة لخدمات Brotli احفظ Crash Dumps حيث تسمح السياسة، وContainer Termination Reasons وKernel Events وRequest Metadata وHash للمدخل المضغوط المشبوه. وفي DNS/TLS احفظ الوجهة الأصلية والمعيارية وعنوان الاتصال وفشل الشهادة. لا تسجل أسرارًا أوPayloads كاملة دون حاجة.

إذا كان فساد الذاكرة ممكنًا، فدوّر Credentials التي استطاعت العملية الوصول إليها حسب نطاق الحادث، وأعد البناء من Artifacts موثوقة، وافحص الحركة الجانبية. Restart وحده يزيل أدلة Volatile ولا يثبت الاحتواء.

ما الذي تفوته الفحوص الشائعة؟

npm audit يفحص Vulnerabilities المعروفة في Package Dependencies. لا يثبت تحديث Runtime أوBrotli المدمج أوTLS أوc-ares. كذلك:

• تحديث package-lock.json لا يغير Runtime في Host؛
• البناء باستخدام Floating Tag لا يثبت Digest النهائية؛
• تحديث CLI لا يثبت أن PM2 أوsystemd أوContainers أوServerless تستخدمها؛
• Readiness ناجحة لا تثبت تغيير كل Replicas؛
• WAF لا يصلح بثقة Memory Safety وIdentity Parsing داخل Runtime.

أفضل الممارسات وAnti-patterns

أفضل الممارسات

• ثبّت خط Node.js نشطًا واستهلك Security Releases بسرعة.
• سجل Runtime Version وArtifact Digest الثابتة في Telemetry.
• تعامل مع Decompression وDNS وTLS كحدود أمنية.
• ارفض Host Representations الملتبسة قبل Allowlist.
• أعد بناء Snapshots وSEA بعد تحديث Runtime أمني.
• اختبر Rollback حتى يستعيد الخدمة دون إعادة صورة ضعيفة بصمت.

Anti-patterns

• افتراض أن npm audit يصلح Node.js نفسه.
• تمرير بيانات مضغوطة عشوائية إلى Workers دون حدود.
• التحقق من Host ثم الاتصال بقيمة مختلفة بعد Normalization.
• إبقاء Pods أوWorkers القديمة بعد تغيير الملفات على Disk.
• ادعاء اختراق من Version Scan وحده.
• استخدام Permission Model كعزل وحيد للكود العدائي.

هل يمكن ترتيب الأولويات؟

يجب تحديث كل الخطوط النشطة المتأثرة. ويمكن ترتيب النشر أولًا للخدمات التي تفك Brotli غير موثوق، أو تقبل Hosts من Tenant، أو تستخدم Custom TLS أوSnapshots/SEA أوPlugins غير موثوقة مع Permission Model. أما الخدمة الداخلية التي لا تحتوي هذه المسارات فما تزال تستفيد من إصلاحات Dependencies والدفاع الإضافي؛ عدم تعرضها للإنترنت سبب للترتيب وليس سببًا للبقاء دون تحديث.

إذا كان Vendor-managed Platform يتحكم في Node.js، فاطلب تأكيد النشر وهوية Runtime المصححة. لا ترفع Exploit Samples لإثبات كلام المزود.

خلاصة تنفيذية

1. احصر كل Node.js 22 و24 و26، بما فيها Build Images وJobs.
2. حدث إلى 22.23.4 أو24.22.1 أو26.12.1.
3. أعد بناء Containers وNative Modules وStartup Snapshots وSEA.
4. اختبر DNS وTLS وBrotli وHTTP Keep-alive وUUID وPermissions في Canary.
5. استبدل كل Workers وتحقق من Digests عبر Fleet.
6. احفظ الأدلة وافصل بين التعرض ومحاولة الاستغلال والاختراق المؤكد.
7. احذف Base Images وDeployment Templates القديمة حتى لا يعيد Autoscaling الثغرة.

اقرأ أيضًا: دليل PHP2Shell والتحديث، وتدوير TLS في Kubernetes، ومنع الانهيار المتسلسل، ومكتبة المقالات الهندسية.

المراجع الأساسية

• Node.js Project — October 21, 2026 security releases
• Node.js v22.23.4 release
• Node.js v24.22.1 release
• Node.js v26.12.1 release
• Node.js documentation — Zlib
• Node.js documentation — DNS
• Node.js documentation — TLS
• Node.js documentation — Permissions
• Unsplash License
• Cong Long Vu — licensed terminal photograph

إعداد: Noor Yasser