في 11 ديسمبر 2025، أعلن فريق React عن ثغرتين جديدتين تؤثران في معمارية React Server Components (RSC):
- حجب الخدمة (Denial of Service): CVE-2025-55184 وCVE-2025-67779 - كشف الشيفرة المصدرية (Source Code Exposure): CVE-2025-55183
اكتشف الباحثون هذه المشكلات أثناء اختبار التصحيحات المرتبطة بثغرة التنفيذ البرمجي عن بُعد الحرجة التي ظهرت في الأسبوع السابق، والمعروفة باسم “React2Shell” (CVE-2025-55182).
وهذا يطرح ثلاثة أسئلة:
- لماذا ظهرت عدة ثغرات خلال فترة قصيرة؟ - هل يعني ذلك أن React Server Components سيئة؟ - ماذا تفعل إذا كان لديك تطبيق React أو Next.js يعمل حاليًا؟
للإجابة عن هذه الأسئلة، نحتاج أولًا إلى فهم مكان حدوث المشكلة.
تتعلق هذه المشكلات بالطريقة التي تفكك بها البنية التحتية لـReact Server Components البيانات القادمة من العميل إلى الخادم، ثم تعيد بناءها. لكن أليست Server Components تُعرض على الخادم فقط؟ متى يقرأ الخادم بيانات قادمة من العميل إذًا؟
صحيح أن Server Components تُعرض على الخادم وترسل الواجهة إلى العميل في صورة React Server Component Payload، المعروف باسم React Flight. هذا تنسيق خاص بـReact، وليس HTML أو JSON عاديًا. لكن Server Components ليست المسار الوحيد؛ فهناك أيضًا Server Functions.
عندما يستدعي Client Component إحدى Server Functions، مثلًا عبر Form Action، يقوم إطار العمل بتسلسل استدعاء الدالة ومدخلاتها في React Flight Payload، ثم يرسل هذا الـPayload إلى الخادم.
وهنا يظهر الحد الأمني المهم: البيانات القادمة من العميل غير موثوقة. وقد يصبح فك تسلسلها (Deserialization) خطرًا إذا تعامل الخادم معها بثقة زائدة ومن دون تحقق صارم. فإذا أرسل المهاجم Payload صُمم خصيصًا لاستغلال خطأ في عملية فك التسلسل (Deserialization)، فقد تحدث مشكلة أمنية خطيرة.
لفهم مكان ظهور الثغرات، تخيل التسلسل التالي:
1. يبدأ الكود الموجود على العميل طلبًا يستدعي Server Function.
2. يحوّل إطار العمل هذا الطلب إلى React Flight Payload. هذا التنسيق منظم ويشبه JSON، لكنه ليس JSON. ويحتوي على معلومات مثل معرّف Server Function وقيم المدخلات بعد تسلسلها.
3. يستقبل الخادم الـPayload، ثم تقوم حزمة من عائلة react-server-dom-*، مثل react-server-dom-webpack، بفك تسلسله وإعادة بناء قيم JavaScript.
4. تُمرَّر القيم الناتجة إلى Server Function. لذلك يجب على الدالة اعتبارها مدخلات غير موثوقة والتحقق منها قبل استخدامها. مرور البيانات عبر Serializer تابع لإطار العمل لا يجعلها آمنة تلقائيًا.
هنا يمكن لخلل في فك التسلسل (Deserialization) أن يتحول إلى ثغرة قابلة للاستغلال. ويعتمد الأثر الدقيق على نوع الثغرة، والحزمة والإصدار المتأثرين، وطريقة دمج إطار العمل، وكيفية تعامل التطبيق مع القيم الناتجة.
لماذا ظهرت عدة ثغرات خلال فترة قصيرة؟ هذا أمر شائع بعد اكتشاف ثغرة حرجة وتصحيحها. فبعد الإعلان عن React2Shell (CVE-2025-55182) ونشر التصحيحات، واصل الباحثون والمشرفون اختبار المسارات القريبة والحالات الطرفية. وأدى هذا الاختبار الإضافي إلى اكتشاف مشكلات أخرى، من بينها ثغرات حجب الخدمة وكشف الشيفرة المصدرية المذكورة أعلاه.
هل يعني ذلك أن React Server Components سيئة؟ بالتأكيد لا. RSC معمارية قوية، وقد توفر فوائد مهمة، منها إبقاء بعض منطق التطبيق على الخادم. لكن أي نظام معقد يعالج مدخلات يتحكم بها المهاجم قد يحتوي على أخطاء تنفيذية. والدرس الصحيح ليس رفض المعمارية، بل تحديث الاعتماديات، والتحقق من كل مدخلات الخادم، ومتابعة التنبيهات الأمنية الرسمية.
ماذا تفعل إذا كان لديك تطبيق React أو Next.js يعمل حاليًا؟ حدّثه فورًا. راجع التنبيهات الأمنية الرسمية لـReact وNext.js، وتحقق من الحزم الموجودة في شجرة الاعتماديات، وثبّت الإصدارات التي تحتوي على الإصلاحات، ثم أعد نشر جميع البيئات المتأثرة. لا تفحص الاعتماديات المباشرة فقط؛ فقد تأتي الحزمة المتأثرة بشكل غير مباشر من خلال إطار العمل.
والخلاصة: كون Server Components تُعرض على الخادم لا يعني أن الخادم لا يستقبل مدخلات من المهاجم. لذلك تبقى فحوصات المدخلات، وتحديث الاعتماديات، وتصميم الحدود الأمنية بعناية أمورًا ضرورية.