1. نظرة عامة على الثغرة

في اليومين الماضيين، انتشرت أنباء عن ثغرة RCE (تنفيذ التعليمات البرمجية عن بُعد) في React عبر إلغاء التسلسل، وقد منحها التقييم الرسمي CVSS درجة كاملة 10.0، مماثلة لـ Log4j في ذلك الوقت. على الفور، انتشرت شائعات زعمت أنها "Log4j للواجهات الأمامية الحديثة"، مما تسبب في حالة من الذعر بين المطورين في العديد من الشركات، فاستيقظ الجميع وهم يبحثون عن الوثائق ويطبقون التصحيحات... وفي الوقت نفسه، ظهرت على الإنترنت أصوات تشكك عديدة، حيث اختبرها البعض ووجدوا أن الثغرة ليست كما تم الترويج لها، بل تتطلب شروطًا معينة للاستغلال. لذلك قررت أن أخصص وقتًا لدراسة هذه الثغرة بعمق.

1.1 معلومات الثغرة

• رقم CVE: CVE-2025-55182
• درجة CVSS: 10.0 (حرجة)
• نوع الثغرة: تلوث سلسلة النموذج الأولي → تنفيذ تعليمات برمجية عن بُعد
• الإصدارات المتأثرة: react-server-dom-webpack < 19.2.0، react-server-dom-turbopack < 19.2.0
• نطاق التأثير: التطبيقات التي تستخدم مكونات خادم React

---

2. تحليل مبدأ الثغرة

2.1 السبب الجذري للثغرة

سبب هذه الثغرة هو ما يلي، في [email protected]، الدالة الرئيسية التي يقوم الخادم من خلالها بتحليل إجراء الخادم هي requireModule (شفرة زائفة):

function requireModule(metadata) {
  var moduleExports = __webpack_require__(metadata[0]);
  // ...
  return "*" === metadata[2]
    ? moduleExports
    : "" === metadata[2]
      ? moduleExports.__esModule
        ? moduleExports.default
        : moduleExports
      : moduleExports[metadata[2]];  // ← نقطة الثغرة
}

2.2 المشكلة الأساسية للثغرة

المشكلة الأساسية للثغرة تكمن في الجزء moduleExports[metadata[2]]، حيث لا يتم التحقق من صحة الجزء metadata[2]، مما يسمح للمهاجم ليس فقط بالوصول إلى خصائص التصدير الخاصة بالوحدة نفسها، بل أيضًا إلى الخصائص الموجودة في سلسلة النموذج الأولي (مثل constructor، __proto__، إلخ). عندما يقوم المهاجم ببناء metadata[0] (على سبيل المثال، توجيهه إلى vm)، يمكنه بعد ذلك بناء metadata[2] لتحقيق تصدير طرق خطيرة من وحدة محددة، مثل vm.runInThisContext، مما يؤدي إلى استغلال الثغرة.

---

3. تحليل استغلال الثغرة

أثناء تحليلي، قمت بالرجوع إلى بيئة الاختبار واستغلال الثغرة التي قدمها ejpir، وتناولت أداة Code Execution gadget vm_runInThisContext كمثال للتحليل، وكانت العملية على النحو التالي (لاحظ أنه في البيئة الحقيقية، ستكون عملية استغلال الثغرة مختلفة إلى حد ما!):

الخطوة 1: استقبال الطلب

أولاً، بعد إرسال الطلب مع الحمولة، نقطة التوقف للحصول على موقع الطلب تكون كما يلي:

الخطوة 2: تحليل بيانات النموذج

بعد ذلك، يتم تنفيذ البرنامج حتى الموقع const formData = parseMultipart(buffer, boundaryMatch[1]);، ثم ندخل إلى parseMultipart

يقوم parseMultipart باستخراج بيانات جسم الطلب وإرجاعها إلى formData

الخطوة 3: استدعاء decodeAction (مدخل الثغرة)

ندخل إلى const actionFn = await decodeAction(formData, serverManifest); موقع حدوث الثغرة

ندخل إلى loadServerReference

الخطوة 4: الكود الأساسي للثغرة requireModule

الآن نصل إلى موقع الكود الأساسي للثغرة requireModule، ندخل إليه

يعيد قيمة id مع ما قبل وبعد # كطريقة للوحدة، ويعيد قيمة المعلمة bound كمعامل للطريقة

الخطوة 5: تنفيذ الحمولة

ندخل إلى actionFn، وننفذ الحمولة النهائية

وبهذا، انتهى استغلال الثغرة!

---

4. ملخص && دفاع

هذه الثغرة في جوهرها ناتجة عن عدم صرامة التحقق من الإدخال، وهذا يتطابق مع Log4j و fastjson. اختبرت أعلاه vm_runInThisContext، في الواقع هذه الثغرة بها أدوات متعددة قابلة للاستغلال، مثل

• vm#runInThisContext
• vm#runInNewContext
• child_process#execSync
• child_process#execFileSync
• child_process#spawnSync
• fs#readFileSync
• fs#writeFileSync
• #constructor
• #__proto__
• #prototype

يمكن للمهاجم باستخدام هذه الثغرة تحقيق:

• تنفيذ التعليمات البرمجية عن بُعد (RCE): عبر vm#runInThisContext أو child_process#execSync لتنفيذ أي أمر نظام
• عمليات نظام الملفات: عبر fs#readFileSync، fs#writeFileSync لقراءة/كتابة أي ملف
• هجمات الثبات: كتابة مفتاح SSH عام، تعديل .bashrc، استبدال ملفات التطبيق، إلخ
• تسريب المعلومات: قراءة ملفات التكوين الحساسة (.env، المفاتيح الخاصة، بيانات اعتماد قاعدة البيانات، إلخ)

بناءً على ذلك، يمكن تقديم إجراءات دفاعية ذات صلة، على النحو التالي

1. دفاع مؤقت

بناءً على ذلك، يمكن أن ينطلق الدفاع المؤقت من هذه الزوايا، يمكن تكوين قواعد في جدار الحماية من تطبيقات الويب (WAF) لاعتراض هذه الحقول الخطيرة، وبالتالي اعتراض الهجمات الضارة في الوقت المناسب. بالإضافة إلى ذلك، يمكن أيضًا إجراء تطابق واعتراض في nginx، على النحو التالي:

# مثال تكوين Nginx
location /formaction {
    # اعتراض الطلبات التي تحتوي على مراجع وحدات خطيرة
    if ($request_body ~* "(vm#|child_process#|fs#|module#)") {
        return 403;
    }
    # اعتراض محاولات تلوث سلسلة النموذج الأولي
    if ($request_body ~* "(#constructor|#__proto__|#prototype)") {
        return 403;
    }
}

2. التحديث في أقرب وقت

قامت الجهة الرسمية حاليًا بإصدار تحديث أمني، قم بالترقية فورًا إلى الإصدار الآمن!:

# ترقية react-server-dom-webpack
npm install react-server-dom-webpack@>=19.2.0

# ترقية react-server-dom-turbopack
npm install react-server-dom-turbopack@>=19.2.0

# مستخدمو Next.js
npm install next@>=15.0.5

الإصدارات التي تم إصلاحها:

• react-server-dom-webpack: >= 19.2.0
• react-server-dom-turbopack: >= 19.2.0
• next.js: >= 15.0.5