Andrew Hanna
Tekunda Team
باختصار: في أوائل ديسمبر 2025، كُشف عن ثغرة حرجة في React Server Components عُرفت باسم React2Shell (CVE-2025-55182). أتاحت الثغرة تنفيذ أوامر عن بُعد من دون مصادقة في إعدادات شائعة من React وNext.js، بما في ذلك الإعدادات الافتراضية. ظهرت الاستغلالات بسرعة في الواقع، واستُخدمت الخوادم المخترقة لتعدين العملات. إذا كان تطبيقك يستخدم React Server Components أو Next.js App Router، فالتصحيح وإعادة النشر ضروريان.
لسنوات، تعلم مهندسو الواجهة الأمامية نموذجا ذهنيا مطمئنا: المتصفح هو الحدود.
كانت شيفرة الواجهة تعمل على العميل، وتتعامل أنظمة الخلفية مع الثقة والأمان، وتساعد الأطر في إبقاء هذه المسؤوليات منفصلة بوضوح. شكّل هذا النموذج طريقة تفكير الفرق في المخاطر والمراجعات والنشر.
كسر React2Shell هذه الفرضية بطريقة عملية جدا.
في الأيام التي تلت الكشف عن CVE-2025-55182، وصلت فرق بأدوار مختلفة إلى الاستنتاج نفسه من اتجاهات مختلفة، ليس بسبب النظرية، بل بسبب ما فعله المهاجمون بعد ذلك.
لم تعد تطبيقات React الحديثة مجرد شيفرة واجهة مستخدم. إنها تنفذ كجزء من بنية الإنتاج، وهذا التحول مكّن حملات انتهازية من تحويل الخوادم المكشوفة إلى أحمال لتعدين العملات.
لم يحدث ذلك بسبب سوء استخدام أو إعدادات غريبة. لقد أثّر على إصدارات منتشرة من React وNext.js تعمل كما هو موثق تماما، ولذلك انتشر الأثر بسرعة.
React2Shell هي ثغرة حرجة في React Server Components (RSC)، وهي ميزة في React تسمح لأجزاء من شيفرة الواجهة بالعمل على الخادم أثناء معالجة طلبات المستخدمين الفعلية.
ما جعل هذه الثغرة مختلفة لم يكن مكانها فقط، بل أيضا مدى اندماجها الطبيعي في معالجة الطلبات المعتادة.
سمحت الثغرة للمهاجمين بتفعيل remote code execution (RCE)، وهو نوع من الهجمات يتيح لشخص تشغيل أوامره على الخادم عبر طلب مصمم خصيصا، من دون تسجيل دخول.
على مستوى عال، جرى الهجوم كالتالي:
عندما أصبحت هذه السلسلة مفهومة، اتضحت الخطورة فورا.
ظهرت إثباتات المفهوم بعد وقت قصير من الكشف. تبعها استغلال نشط بسرعة، فلم يكن هناك وقت طويل بين الفهم والانكشاف.
من أهم دروس React2Shell أن الإعدادات المتأثرة كانت عادية جدا. وهذا الاعتياد نفسه هو ما جعل الأثر ينتشر بهذه السرعة.
لم تكن هذه:
بل كانت:
تغيّر React Server Components جذريا مكان تنفيذ منطق الواجهة. ونتيجة لذلك أصبحت شيفرة الواجهة الآن:
لم ينشئ React2Shell هذا التحول. لكنه أجبر الفرق على مواجهته.
بمجرد أن أصبحت الثغرة علنية، بدأ الاستغلال شبه فوري.
سرعان ما بدأت مزودات السحابة وباحثو الأمن في الإبلاغ عن هجمات حقيقية، وكان كثير منها انتهازيا وليس موجها.
أظهرت الأنظمة المخترقة:
في عدة حالات منشورة، أعادت الفرق نشر الخوادم مرات متعددة ثم أصيبت مرة أخرى. كشف هذا النمط المشكلة الأساسية.
لم تكن المشكلة في التنظيف. كان وقت التشغيل الضعيف لا يزال موجودا.
ساعدت الدفاعات متعددة الطبقات، لكنها لم تستطع تعويض اعتماد أساسي غير مصحح.
على مستوى عال، أصبح React2Shell ممكنا بسبب طريقة قيام React Server Components بتسلسل البيانات وفك تسلسلها عبر بروتوكول React Flight. تمكن المهاجمون من إساءة استخدام هذا المسار للوصول إلى التنفيذ على الخادم، وفي Next.js أمكن تفعيل المسار نفسه عبر سلوك توجيه الطلبات المرتبط بإجراءات الخادم.
للاطلاع على التفصيل الكامل للبروتوكول ومسار الاستغلال والتخفيف، اقرأ التحليل التقني من Darktrace كاملا.
أوضح React2Shell أمرا كان يتطور بهدوء منذ سنوات.
إذا كان إطار الواجهة لديك:
فهو يستحق مستوى التدقيق التشغيلي نفسه لأي خدمة خلفية.
هذا ليس فشلا في هندسة الواجهة. إنه النتيجة الطبيعية لتحول التجريدات القوية إلى بنية إنتاج.
تستبدل الأطر الحديثة الحدود الصريحة بالسرعة وتجربة المطور. هذه المقايضة لا تزيل المسؤولية، بل تنقلها.
مع ظهور الإرشادات، تقاربت أنماط الاستجابة بين المؤسسات. الفرق التي تحركت بسرعة اتبعت الخطة نفسها.
1. تحديد الانكشاف
2. التصحيح وإعادة النشر
3. افتراض حدوث ما بعد الاستغلال
4. التعامل مع ترقيات الأطر كتغييرات إنتاجية.
تحديثات الأطر تؤثر في سلوك وقت التشغيل. ليست تغييرات شكلية.
لم يكسر React2Shell الثقة في React. بل كشف مقدار الثقة التي تحملها الحزم الحديثة افتراضيا.
التحول الحقيقي ليس "التصحيح بسرعة أكبر". بل الاعتراف بأن سلوك الإطار جزء من بنية الإنتاج، والتعامل معه بالانضباط نفسه المطبق على APIs والمصادقة والنشر.
كل منظومة توازن بين:
لا توجد حزمة آمنة تماما، بل حزم مفهومة جيدا.
الفرق التي تعاملت مع الحادثة بأفضل شكل لم تكن صاحبة أكبر عدد من الأدوات. كانت الفرق التي فهمت ما الذي ينفذ وأين، واستطاعت الاستجابة بوعي.
انتشر React2Shell بسرعة ليس لأنه شديد التعقيد، بل لأنه توافق مع طريقة بناء الأطر الحديثة ونشرها.
إذا كنت تشغّل React Server Components أو Next.js App Router في الإنتاج، فتعامل مع الأمر مثل أي حادثة runtime أخرى: صحح، أعد النشر، وتحقق من أنك لم تكن متأثرا بالفعل.
ومن الآن فصاعدا، طبق القاعدة نفسها في كل مكان: إذا كان يعمل على الخادم، فهو يستحق انضباط الخادم.
Andrew Hanna
Serpent Team
Tekunda Team
Tekunda Team
Tekunda Team
Andrew Hanna