ثغرات Next.js في مايو 2026: لماذا يتقدم تسميم ذاكرة RSC على ثغرة SSRF؟

خلاصة ثغرات Next.js في سطر واحد، وما يستحق الأولوية فعلاً

نشرت Next.js في 6 مايو 2026 عدد 13 تحذيراً أمنياً منسقاً، ثم أصدرت النسخ المصححة في 7 مايو: 16.2.6 و15.5.18. انصب اهتمام الصحافة على CVE-2026-44578، أي ثغرة WebSocket SSRF، لأن صورتها لافتة: يطلب المهاجم ترقية اتصال، فيتجه الخادم بنفسه إلى 169.254.169.254، ثم تعيد نقطة نهاية بيانات التعريف بيانات اعتماد IAM. مشهد درامي بالفعل.

لكنها تخص الاستضافة الذاتية فقط. في نشر تديره Vercel وتسبقه Cloudflare، لا يمكن الوصول إلى ذلك المسار. أما التحذير القادر على بلوغ قرّائي فهو ثغرة تسميم ذاكرة RSC المؤقتة متوسطة الخطورة التي لا يتحدث عنها أحد؛ لأن استجابة RSC المسمومة لا تبقى ضمن طلب المهاجم، بل تستقر في ذاكرة التخزين المؤقت المشتركة على الحافة وتُقدَّم لكل زائر حتى أمسح الوسم.

إذا كنتم تشغّلون أي إصدار Next.js >= 13.4.13، فعليكم الترقية هذا الأسبوع. والأسئلة الوحيدة هي: إلى أي إصدار، وبأي ترتيب، وما الذي يجب إعادة اختباره بعد ذلك؟ المصفوفة أدناه هي الفرز الذي طبقته على omidsaffari.com: ‏App Router على Vercel، وأمامهما Cloudflare مع مسح عبر Cache-Tag وخطاف revalidate. وقد قلبت النتيجة ترتيب أولوياتي بعيداً عن ثغرة CVE التي تصدرت العناوين.

ماذا يعني ذلك للمؤسسين غير التقنيين؟

إذا كان منتجكم تطبيق Next.js، فهذه مهمة يجب إنجازها هذا الأسبوع، لا تذكرة تُرحّل إلى قائمة الأعمال المتراكمة. المسألة المالية هنا ليست زمن الاستجابة ولا ساعات المطورين؛ بل إن تسميم صفحة مخزنة مؤقتاً أو تجاوز المصادقة في مسار إدارة يمثل حادثة تهز ثقة العملاء. تكفي صورة واحدة لصفحتكم التسويقية وهي تعرض محتوى المهاجم، أو بلاغ واحد عن دخول شخص إلى /admin بلا جلسة، لتقضوا الأسبوع التالي في التبرير بدلاً من البيع.

اطلبوا من المهندسين إجابة عن سؤال واحد محدد: «هل نستخدم 16.2.6 أم 15.5.18، وهل مسحنا ذاكرة التخزين المؤقت على الحافة بعد النشر؟» إذا كانت الإجابة أقل وضوحاً من ذلك — «نعمل على التصحيح»، أو «الأمر قيد التنفيذ»، أو «ثغرة SSRF لا تؤثر فينا» — فالعمل لم يكتمل. تندرج عمليات النشر ذاتية الاستضافة (ECS وEC2 وKubernetes وأي خادم تديرونه ويشغّل next start) ضمن الفئة الأعلى خطراً، لأنها مكشوفة أمام SSRF إلى جانب بقية الثغرات. اسألوا فريقكم إلى أي فئة تنتمون؛ يجب ألا تستغرق الإجابة أكثر من 10 ثوانٍ.

التحذيرات الـ13 مرتبة بحسب قدرتها على الوصول إلى بنيتكم

المشكلة في كل منشور متداول بصيغة «13 ثغرة CVE، صحّحها الآن» أنه يعامل القائمة كأن عناصرها متساوية، وهي ليست كذلك. لكل تحذير شرط مسبق: استضافة ذاتية، أو Turbopack، أو Cache Components، أو CSP nonces، أو i18n. أما نطاق تعرضكم الفعلي فيقتصر على الحالات التي تتطابق شروطها مع طريقة نشركم. إليكم التحذيرات الـ13 نفسها، لكن مجمعة وفق الشروط اللازمة لاستغلالها.

مجموعة تجاوز Middleware وproxy (5 تحذيرات، معظمها عالية الخطورة). أبرزها GHSA-267c-6grr-h53f، التي تتيح لعنوان URL خاص بالجلب المسبق للمقاطع في App Router تجاوز فحوص مصادقة middleware. وتشمل المجموعة أيضاً متابعة نُشرت في 7 مايو لإصلاح غير مكتمل (GHSA-26hh-7cqf-hhc6) يخص Turbopack، وتجاوزاً عبر مسار اللغة الافتراضية في i18n ضمن Pages Router، وتجاوزاً بحقن معامل في مسار ديناميكي. الشرط المسبق: استخدام middleware في Next.js لفرض المصادقة أو إعادة الكتابة. وهذا ينطبق على الجميع تقريباً.

SSRF، ‏CVE-2026-44578. يستطيع معالج ترقية WebSocket في الخادم ذي الاستضافة الذاتية الوصول إلى نقاط نهاية HTTP داخلية على المنفذ 80، بما فيها بيانات التعريف السحابية. الإصدارات المتأثرة: 13.4.13+ حتى <15.5.16، و16.0.0–<16.2.5، وفي الاستضافة الذاتية فقط. وقد تأكد أن عمليات النشر التي تديرها Vercel غير متأثرة.

حجب الخدمة، تحذيران. الأول هو هجوم RSC DoS القادم من المنبع؛ والثاني هجوم DoS يستنزف الاتصالات في التطبيقات التي فعّلت Cache Components (عالي الخطورة، GHSA-q4gf-8mx6-v5v3). شرط الحالة الثانية: أن تكونوا قد فعّلتم Cache Components صراحة، وهو ما لم تفعله معظم التطبيقات.

تسميم ذاكرة التخزين المؤقت RSC (متوسط الخطورة). تسمح تصادمات مفاتيح كسر التخزين المؤقت في مسار حمولة RSC لطلب مُعد بعناية بتسميم استجابة مخزنة مؤقتاً. الشرط المسبق: تخزين استجابات RSC مؤقتاً في أي نقطة لاحقة، سواء في CDN أو reverse proxy أو حافة Vercel أو Cloudflare. وهذه هي الثغرة المهمة في بنيتي.

XSS، تحذيران. الأول CVE-2026-44581 (متوسط الخطورة) في تطبيقات App Router التي تنشئ CSP nonces، والثاني ثغرة XSS في نصوص beforeInteractive التي تستهلك مدخلات غير موثوقة. الشرطان المسبقان: استخدام CSP مع nonces، أو تمرير مدخلات المستخدم إلى وسم script من نوع beforeInteractive.

دوّنوا الشروط المسبقة التي تنطبق على نشركم؛ تلك هي قائمتكم الحقيقية. بالنسبة إلى omidsaffari.com، النتيجة هي: مجموعة تجاوز middleware (نعم)، وSSRF (لا، فالاستضافة على Vercel)، وRSC DoS (نعم، من المنبع)، وCache Components DoS (لا، لم أفعّلها)، وتسميم ذاكرة RSC المؤقتة (نعم، مع تضخيم أثره)، وCSP nonce XSS (نعم)، وbeforeInteractive XSS (لا). بذلك تتقلص 8 تحذيرات عالية أو متوسطة الخطورة إلى 5 تنطبق عليّ، بينما لا تكون أشهرها صاحبة أوسع نطاق ضرر.

لماذا لا تكون ثغرة SSRF الشهيرة مشكلتكم غالباً، بينما يكون تسميم ذاكرة RSC المؤقتة كذلك؟

تحتاج CVE-2026-44578 إلى أن يتولى خادم next start في جانب Node ترقية WebSocket ويتتبع إعادة التوجيه. لا تمرر Vercel طلباتي عبر ذلك الخادم على نحو يجعل مسار SSRF قابلاً للوصول؛ فالمنصة تنهي اتصالات WebSocket، كما تقع نقطة نهاية بيانات التعريف خلف IMDSv2 بحد للقفزات لن يصمد عبر ذلك المسار أصلاً. وجود Cloudflare أمامها لا يغير النتيجة. ضمن بنية Vercel + Cloudflare، لا تتحقق الصورة الدرامية.

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

Cache-Control: public, s-maxage=300, stale-while-revalidate=86400
Cache-Tag: article:nextjs-may-2026-security-triage

تعني s-maxage=300 أن Cloudflare يحتفظ بتلك الاستجابة لمدة 5 دقائق. وتعني stale-while-revalidate=86400 أنه سيواصل تقديمها ليوم كامل بعد انتهاء صلاحيتها بينما يعيد التحقق منها في الخلفية. أما Cache-Tag فهو وسيلة المسح لديّ: عندما أنشر مراجعة جديدة، يطلق خطاف revalidate عملية مسح للوسم، فيُحذف الكائن.

لنتتبع ما يحدث عند وصول استجابة مسمومة. يستهدف المهاجم مساراً يستغل تصادم إبطال التخزين المؤقت. ترى Cloudflare استجابة قابلة للتخزين، فتحفظها تحت مفتاح ذاكرة التخزين لعنوان URL ذاك، وتمنحها الوسم article:<slug>. بعد ذلك يتلقى كل زائر لذلك المسار حمولة RSC المسمومة من الحافة، لا من الأصل، ومن دون المرور بأي middleware أو قاعدة WAF أضيفها بعد 10 دقائق. فالكائن المسموم أصبح موجوداً بالفعل في نقطة لاحقة. ويظل هناك حتى تنقضي نافذة s-maxage أو يطلق مسار النشر لديّ عملية مسح. قواعد WAF عند الأصل لا تفعل شيئاً لاستجابة موجودة مسبقاً في 300 نقطة حضور.

لهذا فإن الأصل المعرّض للخطر هو سطح المحتوى المنشور — أي مخرجات محرك المحتوى — لا واجهة API داخلية. تصنف قائمة التحذيرات الـ13 ثغرة SSRF على أنها عالية الخطورة، وهذه الثغرة على أنها متوسطة. لكن ترتيب الأثر العملي ينعكس في موقع RSC تسبقه ذاكرة تخزين مؤقت.

خطوات تحديث أمان Next.js بدقة، مع فخ متابعة Turbopack

الخطوة الأولى: اعرفوا الإصدار الفعلي لديكم. قد يعطي package.json انطباعاً مضللاً عن النسخة المثبتة عند استخدام نطاق يبدأ بعلامة caret؛ لذلك افحصوا ملف القفل.

bun pm ls | grep next
# or
npm ls next

بعدها ثبّتوا الإصدار 16.2.6 (مسار Next.js 16) أو 15.5.18 (مسار Next.js 15). ليس 16.2.5، وليس 15.5.16.

bun add next@16.2.6
# or
npm install next@16.2.6 --save-exact

سبب التثبيت الدقيق هو الفخ الذي لا يذكره أحد. صُححت التحذيرات الأصلية الـ13 في 16.2.5 / 15.5.16 بتاريخ 6 مايو. وفي 7 مايو، أصدرت Vercel التحذير GHSA-26hh-7cqf-hhc6، وهو متابعة لإصلاح غير مكتمل لتجاوز middleware عبر الجلب المسبق للمقاطع؛ إذ ظل قابلاً للاستغلال عندما يُخدم الطلب عبر Turbopack. كان من لا يستخدمون Turbopack محميين عند 16.2.5 / 15.5.16، أما مستخدمو Turbopack فلم يكونوا كذلك. الإصلاح الكامل موجود في 16.2.6 / 15.5.18.

إذا كنتم على مسار 13.x أو 14.x، فلن يصل أي تصحيح. لن تنقل Vercel الإصلاحات إلى الإصدارات الأقدم. المعالجة هي الانتقال إلى 15.x أو 16.x، ويجب تقديرها كمشروع ترحيل، لا كأمر bun update. خصصوا أسبوعاً واحداً على الأقل إذا كان التطبيق غير بسيط؛ فمساحة التغييرات غير المتوافقة حقيقية، ولا سيما حول مطابقات middleware وإعدادات التخزين المؤقت الافتراضية في App Router.

بعد اكتمال النشر، امسحوا ذاكرة التخزين المؤقت على الحافة. هذه هي الخطوة الغائبة عن كل شرح آخر قرأته هذا الأسبوع. من دون المسح، تبقى أي حمولة RSC خزنتها Cloudflare قبل تفعيل التصحيح، وقد تكون مسمومة إذا استغلها أحد خلال تلك النافذة، كما يستمر تقديمها من الحافة حتى انتهاء s-maxage. في بنيتي:

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

ثم تحققوا. اختاروا مساراً تحميه مصادقة middleware، وأنشئوا شكل عنوان URL للجلب المسبق للمقاطع كما ورد في شرح التحذير، ثم أعيدوا إرسال الطلب إلى بيئة الإنتاج. يجب أن تكون النتيجة 401 أو 302 أو أياً كانت الاستجابة التي يعيدها middleware للطلبات غير المصادق عليها. أما الحصول على 200 مع محتوى فيعني أن تصحيح middleware لم يُطبّق، وأن المشكلة في النشر لا في Next.js.

ما الذي تعطل في 16.2.6؟ الصورة بلا تجميل

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

تشديد مطابقات middleware لعناوين .rsc والجلب المسبق للمقاطع. غيّر إصلاح التجاوز عبر الجلب المسبق للمقاطع طريقة عمل المطابقات. إذا كان لديكم نمط يعتمد على الشكل القديم — وبخاصة إذا كنتم تستخدمون negative lookahead لاستبعاد مسارات _next وتفترضون أن .rsc تقع دائماً تحتها — فأعيدوا التحقق. اضطررت إلى توسيع مطابقة واحدة كي تلتقط صراحة لاحقة الجلب المسبق للمقاطع على مسار محمي. استغرق الإصلاح 5 دقائق، لكنه كان سيصبح تراجعاً صامتاً لولا أنني أعدت الاختبار بإعادة تشغيل الطلبات.

التعامل مع CSP nonce. يغير إصلاح XSS ‏(CVE-2026-44581) طريقة تمرير nonces أثناء التصيير في App Router. إذا كنتم تنشئون nonces داخل middleware وتشيرون إليها في مكوّن Script، فشغّلوا CSP في وضع report-only لمدة يوم بعد النشر. لم أرصد أي مخالفة، لكن التغيير حقيقي، وسمعت من فريق واحد اضطر إلى تحديث مسار إنشاء nonce لديه.

تغير سلوك Cache Components. إذا كنتم تستخدمون Cache Components في المسار المتأثر بإصلاح DoS الذي يستنزف الاتصالات، فإن الإصلاح يغير كيفية تجميع حالات الإخفاق في إصابة الذاكرة المؤقتة تحت الضغط. أعيدوا اختبار المسارات الساخنة. أنا لا أستخدم Cache Components، ولذلك لم أحتج إلى ذلك.

قائمة التحقق التي نفذتها قبل اعتبار الترقية مكتملة:

[ ] next version pinned to 16.2.6 in lockfile
[ ] middleware auth replay on /admin via segment-prefetch URL → 401
[ ] middleware auth replay via .rsc URL → 401
[ ] RSC cache key sanity: same URL, two clients, identical payload
[ ] forced edge purge after deploy
[ ] CSP report-only on for 24h with no new violations
[ ] one full revalidate cycle on a high-traffic page

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

طبّقوا التصحيح لا WAF، والدرس البنيوي وراء ذلك

لم تصدر Vercel أي قواعد WAF لهذا الإصدار. ينص سجل التغييرات على أن تطبيق التصحيح هو التخفيف الكامل الوحيد، وهم محقون؛ فلا يمكن تصفية أي من هذه التحذيرات بوضوح عند الحافة، لأن أشكال الطلبات الخبيثة تتداخل بشدة مع المشروعة. أصدرت Cloudflare في 6 مايو قواعد WAF وتخفيفات في framework-adapter بوصفها دفاعاً متعدد الطبقات، لا بديلاً عن الترقية. اقرأوا الصياغة بدقة: يوضح سجل تغييرات Cloudflare أن قواعد WAF تقلل التعرض خلال نافذة طرح التحديث، لا بعد انتهائها.

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

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

رقّوا الليلة. ثبّتوا 16.2.6 أو 15.5.18، ثم امسحوا ذاكرة التخزين المؤقت. ثغرة CVE صاحبة الصورة ليست ما يستحق القلق؛ الأولوية للثغرة متوسطة الخطورة التي تمس كل صفحة مخزنة مؤقتاً.