ช่องโหว่ deserialization ใน React Server Components: เข้าใจโปรโตคอล Flight ก่อนจะถูกโจมตี

React Server Components ส่งข้อมูลด้วยโปรโตคอลสตรีมชื่อ Flight ซึ่งไม่ได้ส่งแค่ HTML หรือ JSON แต่ส่งคำสั่งให้ฝั่งไคลเอนต์ประกอบออบเจ็กต์ที่ทำงานได้ขึ้นมาใหม่ บทความนี้อธิบายว่าจุดใดกลายเป็นช่องโหว่ ทำไม React2Shell ถึงได้คะแนน CVSS 10.0 และแนวทางป้องกันที่ควรทำเรียงตามลำดับความสำคัญ

โปรโตคอล Flight คืออะไร

Flight เป็นโปรโตคอลสตรีมมิงเฉพาะของ React ที่ใช้ส่งผลลัพธ์ของ Server Components ไปยังเบราว์เซอร์ รูปแบบข้อมูลเป็นข้อความแบ่งบรรทัดที่มีอักขระนำหน้าพิเศษอย่าง $, $:, $F เพื่อบอกว่าแต่ละชิ้นคืออะไร แล้วรันไทม์ฝั่งไคลเอนต์จะประกอบข้อมูลเหล่านั้นกลับขึ้นมาเป็นทรีของคอมโพเนนต์ การอ้างอิงโมดูล และปลายทางเรียกฟังก์ชันฝั่งเซิร์ฟเวอร์

ความต่างที่สำคัญคือ JSON บรรยาย "ข้อมูล" แต่ Flight บรรยาย "สิ่งที่ต้องประกอบขึ้นมา" ซึ่งรวมถึงการอ้างอิงที่เรียกใช้งานได้ คอมโพเนนต์ที่โหลดแบบ lazy และสถานะแบบ async เมื่อโปรโตคอลมีความสามารถระดับนี้ ตัวแยกวิเคราะห์ข้อมูลจึงกลายเป็นพื้นที่โจมตีโดยปริยาย

จุดที่กลายเป็น sink

ระบบอักขระนำหน้าสร้างจุดรับข้อมูลที่อันตรายหลายจุด ตัวอย่างเช่น $: ใช้เดินเข้าไปอ่านพรอเพอร์ตี้ซ้อนกันเป็นชั้น ๆ, $F สร้างการอ้างอิงไปยัง Server Action ที่เรียกได้, $@ เปิดให้เข้าถึงออบเจ็กต์ภายในแบบดิบ, $B กระตุ้นตัวจัดการ blob และ $L สั่งเลื่อนการโหลดคอมโพเนนต์ ผลรวมคือผู้โจมตีสามารถมีอิทธิพลต่อสิ่งที่ตัวแยกวิเคราะห์จะเรียกใช้ สร้างขึ้น และเปิดเผยออกมาได้

React2Shell ทำงานอย่างไร

ช่องโหว่ CVE-2025-55182 หรือที่รู้จักในชื่อ React2Shell ได้คะแนน CVSS 10.0 ซึ่งเป็นระดับสูงสุด ต้นเหตุอยู่ที่ฟังก์ชันภายในที่เดินอ่านพรอเพอร์ตี้ตามเส้นทางที่ได้รับมาโดยไม่ตรวจสอบ ผู้โจมตีจึงใช้เส้นทางอย่าง __proto__:constructor:constructor เพื่อไต่ห่วงโซ่ prototype ไปจนถึงตัวสร้างฟังก์ชันของจาวาสคริปต์ จากนั้นอ้างอิงชิ้นข้อมูลดิบเพื่อให้ได้ตัวจับต้องที่แก้ไขได้ แทรกแซงการคลี่คลาย Promise แล้วกระตุ้นตัวจัดการ blob ให้รันโค้ดของผู้โจมตี

ผลลัพธ์คือการรันโค้ดจากระยะไกลโดยไม่ต้องยืนยันตัวตน และใช้คำขอ HTTP เพียงคำขอเดียว ซึ่งเป็นสถานการณ์ที่เลวร้ายที่สุดเท่าที่แอปพลิเคชันเว็บจะเจอได้

ช่องโหว่อื่นในตระกูลเดียวกัน

นอกจาก React2Shell ยังมีช่องโหว่ที่มาจากรากเดียวกันอีกหลายรายการ ได้แก่ CVE-2025-55184 และ CVE-2025-67779 ที่ทำให้บริการหยุดทำงานจากการเรียก Promise ซ้ำไม่รู้จบ, CVE-2026-23864 ที่ทำให้หน่วยความจำหมดจากการเก็บบัฟเฟอร์โดยไม่มีขีดจำกัด, CVE-2025-55183 ที่ทำให้ซอร์สโค้ดรั่วเมื่อฟังก์ชันถูกแปลงเป็นสตริง และ CVE-2026-27978 ที่เปิดทางข้ามการป้องกัน CSRF ผ่านการจัดการเฮดเดอร์ Origin ที่เป็นค่า null ใน Next.js

แนวทางป้องกันเรียงตามลำดับความสำคัญ

อันดับหนึ่งคือตรวจสอบความถูกต้องของอาร์กิวเมนต์ทุกตัวที่ส่งเข้า Server Action ด้วยไลบรารีอย่าง Zod หรือ Valibot ก่อนนำไปใช้ อย่าเชื่อว่าข้อมูลที่มาถึงฟังก์ชันฝั่งเซิร์ฟเวอร์ผ่านการกรองมาแล้ว อันดับสองคือใช้แพ็กเกจ server-only กับโมดูลที่ห้ามหลุดไปฝั่งไคลเอนต์ อันดับสามคือเสริมการป้องกัน CSRF ด้วยคุกกี้แบบ SameSite=Strict และโทเคน CSRF ที่ตรวจสอบเอง ไม่พึ่งค่าเริ่มต้นของเฟรมเวิร์กเพียงอย่างเดียว

อันดับสี่คืออัปเดต React ให้เป็นเวอร์ชันที่แก้ไขแล้ว โดยขั้นต่ำคือ 19.0.1, 19.1.2 หรือ 19.2.1 ขึ้นไป และถ้าต้องการครอบคลุมทุกช่องโหว่ในชุดนี้ควรอยู่ที่ 19.0.4, 19.1.5 หรือ 19.2.4 ขึ้นไป อันดับห้าคือใช้ Taint API เป็นเครื่องช่วยเตือนระหว่างพัฒนา แต่ต้องเข้าใจว่ามันไม่ใช่เส้นแบ่งความปลอดภัยจริง และอันดับสุดท้ายคือตั้งกฎบน WAF ให้บล็อกเพย์โหลดที่มีรูปแบบอย่าง __proto__ และ constructor:constructor ซึ่งเป็นชั้นป้องกันเสริม ไม่ใช่ชั้นหลัก

สำหรับทีมไทยที่ใช้ Next.js กับ App Router ในงานลูกค้า สิ่งที่ควรทำทันทีคือตรวจเวอร์ชัน React ในทุกโปรเจกต์ที่ยังดูแลอยู่ แล้วจัดลำดับการอัปเดตตามความเสี่ยงของระบบ โดยเฉพาะระบบที่เปิดให้บุคคลภายนอกส่งข้อมูลเข้ามาได้โดยไม่ต้องล็อกอิน