Next.js 16.4.1: عالج مساري RCE الحرجين بأمان

أصدرت Next.js النسختين 16.4.1 و15.5.28 لمعالجة مساري تنفيذ أوامر عن بُعد دون مصادقة ومسار حجب خدمة. ولا تتطابق شروط المسارات الثلاثة: تصل إحدى الثغرتين الحرجتين إلى Image Optimization API على Linux المعتمد على glibc عند معالجة SVG، بينما تصل الأخرى إلى تطبيقات Next.js 16 التي تستخدم Cache Components وتعيد عدة Typed Arrays من دالة use cache. أما الثغرة عالية الخطورة فتستهدف تطبيقات App Router التي تحتوي Server Action واحدة على الأقل.

الاستجابة العملية هي اكتشاف Major Line الفعلية والخصائص المكشوفة في كل Deployment، ثم تحديث تطبيقات 15.x إلى 15.5.28 على الأقل وتطبيقات 16.x إلى 16.4.1 على الأقل، وإعادة بناء Artifacts ثابتة، وإثبات أن Load Balancer أوServerless Alias أوRollback Target لا يوجّه إلى Process قديمة. لا تقول النشرات الرسمية التي راجعتها في 2 نوفمبر 2026 إن استغلالًا نشطًا رُصد. وجود نسخة متأثرة سبب لتحديث عاجل، وليس دليلًا على حدوث اختراق.

النطاقات المتأثرة والمصححة والشروط وبيانات Workaround حقائق موثقة من Maintainers. أما Inventory وRollout وVerification وتصميم أدلة الحوادث فهي إرشادات هندسية.

الخلاصة أولًا

استخدم جدول القرار قبل تغيير الإنتاج:

في ثغرة Image Optimization، تذكر النشرة أن النطاق المتأثر هو Next.js 10.0.0 حتى 15.5.27، والنسخ الأكبر من 16.0.0 حتى 16.4.0، وأن 15.5.28 و16.4.1 مصححتان. كما تذكر أن ضمان استخدام Sharp 0.35.5 أو أحدث Workaround ممكن، بينما يضمن تحديث Next.js أن Fresh Install تحصل على Dependency مصححة.

أما Cache Components RCE فتؤثر في Next.js 16.0.0 حتى 16.4.0، وإصلاحها في 16.4.1. وتؤثر Server Actions DoS في 13.0.0 حتى 15.5.27 و16.0.0 حتى 16.4.0، وإصلاحها في 15.5.28 و16.4.1.

ماذا تثبت النشرات الثلاث؟

### حرجة: Image Optimization مع SVG

تصف نشرة Image Optimization ثغرة متعلقة بالذاكرة في مكتبة Upstream. على Linux المعتمد على glibc، قد يتعرض تطبيق يستخدم Image Optimization API مع SVG لتنفيذ أوامر عن بُعد دون مصادقة. تصنف النشرة الخطورة Critical وتربطها بـCVE-2026-96889.

لا تختصرها إلى “كل SVG يؤدي إلى RCE”. الحد الموثق يجمع Next.js Image Optimization وSVG وglibc Linux. تقديم SVG ثابت مباشرة من Web Server آخر ليس المسار نفسه تلقائيًا. وفي المقابل، قد يعالج تطبيق لا يقبل User Uploads عمدًا صورًا بعيدة أوCMS Assets، لذلك افحص Configuration وTraffic الفعلية.

### حرجة: Cache Components وTyped Arrays

تؤثر نشرة Cache Components في تطبيقات Next.js 16 التي تستخدم App Router وCache Components عندما تعيد دالة use cache عدة Typed Arrays. تقول النشرة إن ذلك قد يؤدي إلى RCE دون مصادقة، ولا تقدم Workaround معروفًا. حدّث إلى 16.4.1 أو أحدث حتى لو لم يجد بحث سريع شكل الإرجاع نفسه؛ فقد تخفيه Wrappers أوShared Utilities أوGenerated Code.

### عالية: حجب خدمة عبر Server Actions

تقول نشرة Server Actions إن Requests مصاغة قد تسبب استهلاك CPU مرتفعًا يمنع Process نفسها من معالجة طلبات أخرى. الشرط الموثق App Router مع Server Action واحدة على الأقل. تقع تطبيقات Pages Router وتطبيقات App Router بلا Server Actions خارج التكوين المذكور. ولا تعرض النشرة حلًا غير التحديث.

هذه ثلاثة مسارات منفصلة وصلت إصلاحاتها في الإصدارين نفسيهما. قد يتعرض Deployment لمسار واحد أواثنين أوالثلاثة. لا تربط أولوية التحديث بإثبات كل شرط أولًا؛ فقد تكون Feature Inventory ناقصة، والمساران الحرجان قابلان للوصول عبر الشبكة بلا صلاحيات مسبقة.

ابنِ Inventory للنسخة العاملة فعليًا

ابدأ بسجل لكل Deployment لا بتخمين نسخة Repository:

{
  "service": "storefront-web",
  "next_version": "16.4.0",
  "sharp_version": "0.35.4",
  "base_os": "debian-glibc",
  "app_router": true,
  "cache_components": true,
  "use_cache_typed_arrays": "unknown",
  "server_actions": true,
  "image_optimizer": true,
  "svg_sources": ["cms", "remote-cdn"],
  "artifact": "sha256:...",
  "rollback_artifact": "sha256:...",
  "owner": "web-platform"
}

هذا Internal Inventory Schema وليس Next.js Configuration.

لكل Production وPreview وWorker وDisaster-Recovery Target سجّل:

• نسخة Next.js في Lockfile وداخل Artifact النهائية؛
• نسخة Sharp المحلولة داخل Artifact نفسها؛
• Base Image وعائلة libc، لا Node.js فقط؛
• استخدام App Router وCache Components وuse cache وServer Actions وImage Optimization؛
• مصادر SVG من Uploads أوCMS أوremotePatterns أوLoaders أوخدمات داخلية؛
• Deployment URL وLoad-balancer Target وServerless Alias وRegion؛
• Image Digest أوFunction Bundle Hash أوPlatform Deployment ID؛
• Process Start Time وRelease Identifier في Observability؛
• Rollback وAutoscaling Artifacts التي قد تعيد نسخة متأثرة.

فحوص محلية مفيدة:

npm ls next sharp
node -p "require('next/package.json').version"
node -p "require('sharp/package.json').version"
~~

شغّلها داخل Runtime Image أوFunction Bundle النهائية متى أمكن. قد يحل Developer Laptop Optional Dependency أوArchitecture أوLockfile State مختلفة.

## حدّث دون إنشاء Rollback زائف

لتطبيق 15.x ثبّت Next.js 15.5.28 على الأقل. ولتطبيق 16.x ثبّت 16.4.1 على الأقل. يصلح إصدار مدعوم أحدث يحتوي الإصلاح، لكن لا تدمج التحديث العاجل مع Major Migration غير مختبرة إلا إذا تعذر دعم المسار الحالي.

التسلسل المقترح:

1. أنشئ Security Branch من Production Revision؛
2. حدّث Dependency المباشرة إلى النسخة المصححة داخل Major Line نفسها؛
3. أعد توليد Lockfile بالـPackage Manager والـRegistry المعتمدين؛
4. تحقق من Resolved Dependency Graph ومنها Sharp؛
5. ابنِ Artifact ثابتة جديدة من Dependency Cache نظيفة؛
6. اختبر App Router وServer Actions وCache Components والصور؛
7. افحص SBOM أوPackage Inventory النهائية لاSource Manifests فقط؛
8. وقّع Artifact أوأنشئ Attestation وفق سياسة Supply Chain؛
9. نفّذ Canary على Cohort إنتاج حتمية؛
10. استبدل كل Instance قديمة واحذف Vulnerable Rollback Artifacts من المسارات الآلية.

لا تعتبر `package.json` إثباتًا. قد تبقي Caret Range أوLockfile قديمة أوMonorepo Override أوPackage Resolution أوStandalone Output أوCached Serverless Layer الكود القديم في الخدمة.

## اختبر كل سطح بأمان

هدف التحقق إثبات السلوك الطبيعي، لا إعادة إنتاج الاستغلال.

### Image Optimization

- حمّل Raster وSVG Assets معتمدة عبر مسارات الإنتاج؛
- تحقق من remotePatterns وCustom Loaders وCDN Rewriting؛
- اختبر صورًا مفقودة وكبيرة وMalformed-but-benign في بيئة اختبار؛
- تحقق من Cache Keys وContent Types والأبعاد وFallback؛
- راقب Memory وCrashes وImage-worker Errors أثناء Canary.

### Cache Components

- اختبر Cached Functions بقيم Scalar وBuffers وTyped Arrays المستخدمة؛
- تحقق من Hits وMisses وRevalidation وSerialization عبر Deployments؛
- أثبت أن المحتوى المخزن يبقى ضمن Route Parameters وTenant Context الصحيحة؛
- قِس الصحة قبل مقارنة Latency.

### Server Actions

- اختبر كل Action حرجة بطلبات Authorized وUnauthorized؛
- تحقق من Input Validation وCSRF وOrigin Policy الخاصة بالتطبيق؛
- اختبر Cancellation وTimeouts وConcurrency داخل Bounded Load Test؛
- راقب Event-loop Lag وCPU Saturation وQueues وProcess Restarts.

نجاح الاختبارات يثبت توافق الإصدار المصحح، ولا يثبت أن المسار القديم لم يُستغل.

## نفّذ Rollout كاستبدال للعمليات

الهدف ليس نجاح Deployment Command، بل عدم قدرة أي Process متأثرة على استقبال Traffic.

1. انشر Artifact المصححة إلى Canary معزولة؛
2. تحقق من Release ID ونسخة Next.js وImage Digest أثناء التشغيل؛
3. أرسل Traffic ممثلة للـApp Router وPages Router والصور وActions؛
4. راقب Error Rate وp95 وCPU وMemory وEvent-loop Lag وImage Failures؛
5. توسع Failure Domain أوRegion واحدة في كل مرة؛
6. اسحب Traffic من العمليات القديمة وأنهِها؛
7. راجع Load-balancer Membership وServerless Aliases وEdge Routes؛
8. أثبت أن Autoscaling Templates وScheduled Jobs تستخدم Artifacts مصححة فقط؛
9. احتفظ بـFixed Rollback Artifact مختبرة؛
10. سجّل Completion Evidence لكل Target.

إذا فشلت Canary بسبب تطبيق، ارجع إلى Artifact مصححة أخرى فقط. العودة إلى 15.5.27 أو16.4.0 تعيد التعرض حتى لو أعادت الوظيفة.

## الاحتواء أثناء بناء Artifact المصححة

الاحتواء مؤقت ومحدد للمسار:

- في Image Optimization، توثق النشرة Sharp 0.35.5 أو أحدث كـWorkaround، لكن تحديث Next.js يظل الإصلاح الأنظف على مستوى Release.
- أزل مصادر SVG العامة غير الضرورية، وأوقف Image-loader Routes غير المستخدمة فقط إذا تحمل المنتج التغيير.
- قيّد Preview وAdmin Deployments التي لا يجب أن تكون عامة.
- قد تقلل Rate Limits وWAF حجم الطلبات الضارة، لكنها ليست Vendor Fix لمساري RCE.
- لا يوجد Workaround موثق لـCache Components RCE أوServer Actions DoS؛ أعط التحديث الأولوية.

لا تضف Payload Signatures تخمينية؛ عدم ظهورها في Logs لا يثبت الأمان، وقد تكسر Rule هشة Traffic شرعية.

## افصل Patch Evidence عن Incident Evidence

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

1. كانت Package متأثرة موجودة؛
2. توفرت شروط Feature وPlatform؛
3. استطاع مسار شبكة غير موثوق الوصول؛
4. ظهرت Crashes أوCPU Spikes أوRequests مشبوهة؛
5. تأكد Unauthorized Execution أوData Access أوPersistence.

راجع أدلة تناسب المسارات:

- Node.js Crashes أوCore Dumps أوContainer Restarts بلا تفسير؛
- Memory Faults مفاجئة في Image Workers؛
- CPU مرتفع وEvent-loop Lag وRequest Pileups؛
- Child Processes أوOutbound Connections غير متوقعة؛
- تغييرات Files أوRuntime Layers أوEnvironment Variables أوDeployment Aliases؛
- وصول إلى Secrets أوCloud Credentials أوخدمات داخلية؛
- Scheduled Tasks أوStartup Hooks أوImages معدلة؛
- فجوات بين CDN وLoad Balancer وPlatform وApplication Logs.

Crash أوScan دليل يستحق التحقيق وليس اختراقًا مؤكدًا. إذا وُجد دليل تنفيذ، اعزل Target، واحفظ Forensic Material، ودوّر Secrets القابلة للوصول، وأعد البناء من Artifact مصححة موثوقة، وافحص الأنظمة المجاورة. التحديث يغلق المسار ولا يمحو آثارًا سابقة.

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

- ثبّت Framework Lines مدعومة واشترك في Advisories.
- ابنِ Inventory للميزات والاعتمادات لكل Artifact منشورة.
- اعزل Image Processing في Workload قليلة الصلاحيات ومحدودة الموارد.
- قيّد Remote Image Sources وتعامل مع CMS Assets كمدخل غير موثوق.
- استخدم Immutable Artifacts وأظهر Release ID في Telemetry.
- راقب Event-loop Lag وCPU وMemory وRestarts وImage Errors.
- اختبر Cache Components وServer Actions كعقود إصدار.
- احتفظ بـRollback Artifacts مصححة وموقعة ومختبرة.
- احتفظ بTelemetry كافية لمراجعة الحوادث.
- أعد فحص النشرات عندما يحدّث Maintainers النطاقات.

## Anti-patterns والقيود

- الادعاء بأن كل تطبيق Next.js قابل للاستغلال عبر المسارات الثلاثة.
- اعتبار SVG ثابت خطرًا بلا مسار Image Optimization الموثق.
- فحص `package.json` فقط وتجاهل Lockfile وRuntime Bundle.
- تحديث Sharp وحدها مع إبقاء Next.js متأثرة كحالة دائمة.
- استخدام WAF بدل 16.4.1 أو15.5.28.
- تشغيل Exploit عام على الإنتاج.
- اعتبار CPU Spike إثبات اختراق.
- اعتبار البحث النظيف في Logs إثبات عدم الاستغلال.
- إبقاء Serverless Aliases أوPreview Deployments أوRollback Images متأثرة.
- دمج التحديث العاجل مع إعادة كتابة واسعة.

لا تثبت النشرات أن كل Hosting Model يستخدم Native Dependency نفسها أوProcess Lifetime نفسها. يجب التحقق من Serverless وContainers وManaged Deployments انطلاقًا من Artifact وRuntime الفعليتين.

## قائمة تنفيذية

1. احصر كل Next.js Deployment ونسخته العاملة.
2. سجّل App Router وCache Components و`use cache` وServer Actions والصور.
3. حدد glibc Linux وكل مصدر SVG.
4. حدّث 15.x إلى 15.5.28 على الأقل و16.x إلى 16.4.1 على الأقل.
5. أعد توليد Lockfile وتحقق من Dependency Tree.
6. ابنِ Artifact نظيفة وثابتة وأنشئ Attestation.
7. اختبر الصور وCache وActions بلا Exploit Payloads.
8. نفّذ Canary مع CPU وMemory وEvent-loop وError Telemetry.
9. استبدل كل Process وAlias وTemplate وRollback Artifact قديمة.
10. راجع الأدلة منفصلة وصعّد فقط عند Effects مؤكدة.

اقرأ أيضًا: [تحديث Node.js الأمني في أكتوبر 2026](https://nooryasser.com/ar/articles/nodejs-october-2026-security-release-patch-guide/)، و[تحديث NGINX الأمني](https://nooryasser.com/ar/articles/nginx-october-2026-security-patch-guide/)، و[الاستجابة لتسرب سجلات Docker Desktop](https://nooryasser.com/ar/articles/docker-desktop-cve-2026-114409-credential-logs-response/)، و[مركز Cloud وDevOps وKubernetes](https://nooryasser.com/ar/topics/cloud-devops-kubernetes/)، و[خدمات Backend وAPIs](https://nooryasser.com/ar/services/backend-apis/).

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

- [Next.js — نشرة Image Optimization RCE](https://github.com/vercel/next.js/security/advisories/GHSA-2464-fhr4-w9xw)
- [Next.js — نشرة Cache Components Typed-array RCE](https://github.com/vercel/next.js/security/advisories/GHSA-673q-mjm6-r5xr)
- [Next.js — نشرة Server Actions DoS](https://github.com/advisories/GHSA-p3m5-59mp-jv5r)
- [Next.js — إصدار 16.4.1](https://github.com/vercel/next.js/releases/tag/v16.4.1)
- [Next.js — إصدار 15.5.28](https://github.com/vercel/next.js/releases/tag/v15.5.28)
- [Wikimedia Commons — مركز بيانات Paris Digital Park](https://commons.wikimedia.org/wiki/File:Paris_Digital_Park_ou_data_center_de_La_Courneuve_5.jpg)
- [Creative Commons — CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/)

إعداد: Noor Yasser

إعداد: Noor Yasser