เปิดเผยช่องโหว่ DoS และการเปิดเผยซอร์สโค้ดใน React Server Components

• มีการค้นพบและเปิดเผยช่องโหว่ใหม่ใน React Server Components ได้แก่ การปฏิเสธการให้บริการ (DoS) และ การเปิดเผยซอร์สโค้ด
• ช่องโหว่นี้ไม่สามารถนำไปสู่ การรันโค้ดจากระยะไกล (RCE) ได้ แต่ยังมีความเสี่ยงที่เซิร์ฟเวอร์จะหยุดทำงานหรือโค้ดรั่วไหล
• แพ็กเกจที่ได้รับผลกระทบคือ react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack ในเวอร์ชัน 19.0.0~19.2.2 และเวอร์ชันที่แก้ไขแล้วคือ 19.0.3, 19.1.4, 19.2.3
• ช่องโหว่ DoS (CVE-2025-55184, CVE-2025-67779) สามารถทำให้เซิร์ฟเวอร์เข้าสู่ลูปไม่สิ้นสุดผ่านคำขอ HTTP ที่เป็นอันตราย ส่วน ช่องโหว่การเปิดเผยซอร์สโค้ด (CVE-2025-55183) อาจทำให้มีการส่งคืนบางส่วนของโค้ดใน server function
• ทีม React แนะนำให้อัปเกรดทันที และอธิบายว่าการเปิดเผยเพิ่มเติมครั้งนี้เป็น กระบวนการปกติของรอบการตอบสนองด้านความปลอดภัย

---

ภาพรวมของช่องโหว่ที่เพิ่งเปิดเผย

• นักวิจัยด้านความปลอดภัยพบช่องโหว่เพิ่มเติมอีกสองรายการระหว่างการตรวจสอบ แพตช์ของช่องโหว่ร้ายแรงที่เปิดเผยเมื่อสัปดาห์ก่อน
• ช่องโหว่ใหม่ไม่สามารถนำไปสู่ การรันโค้ดจากระยะไกล (RCE) ได้ และ แพตช์ React2Shell เดิมยังคงใช้ได้
• ช่องโหว่ที่เปิดเผยใหม่มีดังนี้
  • การปฏิเสธการให้บริการ (DoS) — CVE-2025-55184, CVE-2025-67779 (CVSS 7.5, ระดับความรุนแรงสูง)
  • การเปิดเผยซอร์สโค้ด — CVE-2025-55183 (CVSS 5.3, ระดับความรุนแรงปานกลาง)
• ทีม React แนะนำให้ อัปเกรดทันที

ความไม่สมบูรณ์ของแพตช์เดิม

• แพตช์ในเวอร์ชัน 19.0.2, 19.1.3, 19.2.2 ที่ปล่อยเมื่อสัปดาห์ก่อนยังไม่สมบูรณ์ จึงต้องอัปเดตอีกครั้ง
• การแก้ไขอย่างสมบูรณ์รวมอยู่ใน เวอร์ชัน 19.0.3, 19.1.4, 19.2.3
• ควรปฏิบัติตาม คำแนะนำการอัปเดต จากโพสต์ก่อนหน้า
• จะมีการเปิดเผยรายละเอียดเพิ่มเติมหลังจากการปล่อยแพตช์เสร็จสมบูรณ์

แพ็กเกจและเวอร์ชันที่ได้รับผลกระทบ

• ช่องโหว่นี้อยู่ในแพ็กเกจและเวอร์ชันเดียวกับ CVE-2025-55182
• เวอร์ชันที่ได้รับผลกระทบ: 19.0.0~19.2.2
• แพ็กเกจที่ได้รับผลกระทบ:
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• เวอร์ชันที่แก้ไขแล้ว: 19.0.3, 19.1.4, 19.2.3
• แอปที่ไม่ได้ใช้เซิร์ฟเวอร์หรือไม่รองรับ React Server Components จะไม่ได้รับผลกระทบ

รูปแบบทั่วไปของการเปิดเผยช่องโหว่ต่อเนื่อง

• หลังจาก มีการเปิดเผย CVE ระดับร้ายแรง มักจะพบช่องโหว่เพิ่มเติมระหว่างการวิเคราะห์เส้นทางโค้ดที่เกี่ยวข้อง
• มีการยกตัวอย่างกรณีที่มีการรายงาน CVE เพิ่มเติมหลัง Log4Shell
• การเปิดเผยเพิ่มเติมลักษณะนี้ หมายความว่ากระบวนการตอบสนองด้านความปลอดภัยกำลังทำงานตามปกติ

เฟรมเวิร์กและบันเดลเลอร์ที่ได้รับผลกระทบ

• เฟรมเวิร์กและบันเดลเลอร์ต่อไปนี้รวมแพ็กเกจ React ที่มีช่องโหว่ไว้หรือมีการพึ่งพาแพ็กเกจดังกล่าว
  • next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, rwsdk
• ควรปฏิบัติตาม คำแนะนำการอัปเดต จากโพสต์ก่อนหน้า

มาตรการบรรเทาจากผู้ให้บริการโฮสติ้ง

• มีการทำงานร่วมกับผู้ให้บริการโฮสติ้งหลายรายเพื่อใช้ มาตรการบรรเทาชั่วคราว
• อย่างไรก็ตาม ไม่ควรพึ่งพามาตรการเหล่านี้ และควร อัปเดตทันที

แนวทางที่เกี่ยวข้องกับ React Native

• ผู้ที่ใช้ React Native เพียงอย่างเดียวไม่จำเป็นต้องดำเนินการเพิ่มเติม
• ใน สภาพแวดล้อมแบบ monorepo จำเป็นต้องอัปเดตเฉพาะแพ็กเกจต่อไปนี้
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• ไม่จำเป็นต้องอัปเดต react และ react-dom
• รายละเอียดที่เกี่ยวข้องสามารถดูได้จาก React Native GitHub issue

ระดับความรุนแรงสูง: การปฏิเสธการให้บริการ (DoS)

• CVE-2025-55184, CVE-2025-67779, CVSS 7.5
• หากมีการส่งคำขอ HTTP ที่เป็นอันตรายไปยัง endpoint ของ React server function อาจทำให้เกิด ลูปไม่สิ้นสุด ระหว่างกระบวนการ deserialize
• โปรเซสของเซิร์ฟเวอร์อาจหยุดทำงานและใช้ CPU มากผิดปกติ
• แม้จะไม่ได้ implement endpoint ของ server function โดยตรง หากเป็น แอปที่รองรับ React Server Components ก็อาจมีช่องโหว่ได้
• แพตช์ที่ปล่อยวันนี้แก้ปัญหาด้วยการ ป้องกันลูปไม่สิ้นสุด
• เนื่องจากการแก้ไขครั้งแรกยังไม่สมบูรณ์ จึงมีการเสริมด้วยช่องโหว่เพิ่มเติม (CVE-2025-67779)

ระดับความรุนแรงปานกลาง: การเปิดเผยซอร์สโค้ด

• CVE-2025-55183, CVSS 5.3
• คำขอ HTTP ที่เป็นอันตรายอาจทำให้มีการ ส่งคืนบางส่วนของซอร์สโค้ด ของ server function
• เกิดขึ้นเมื่อ server function มีการเปิดเผยอาร์กิวเมนต์แบบสตริงอย่างชัดเจนหรือโดยปริยาย
• ในโค้ดตัวอย่าง อาจมีการเปิดเผย ค่าลับที่ฮาร์ดโค้ดไว้ เช่น คีย์เชื่อมต่อฐานข้อมูล
• แพตช์แก้ปัญหาด้วยการ ป้องกันไม่ให้ซอร์สโค้ดของ server function ถูกแปลงเป็นสตริง
• ขอบเขตของการเปิดเผยจำกัดอยู่ที่โค้ดภายใน server function และ ค่าลับขณะรันไทม์ (process.env.SECRET เป็นต้น) ไม่ได้รับผลกระทบ
• จำเป็นต้องตรวจสอบโดยอ้างอิงจาก production bundle

ไทม์ไลน์

• 3 ธันวาคม: Andrew MacPherson รายงานการเปิดเผยโค้ดต่อ Vercel และ Meta Bug Bounty
• 4 ธันวาคม: RyotaK รายงานช่องโหว่ DoS
• 6 ธันวาคม: ทีม React ยืนยันทั้งสองปัญหาและเริ่มการตรวจสอบ
• 7 ธันวาคม: ร่างวิธีแก้ไขเบื้องต้นและวางแผนการตรวจสอบความถูกต้อง
• 8 ธันวาคม: แจ้งผู้ให้บริการโฮสติ้งและโครงการโอเพนซอร์ส
• 10 ธันวาคม: ใช้มาตรการบรรเทาและตรวจสอบแพตช์เสร็จสิ้น
• 11 ธันวาคม: Shinsaku Nomura รายงาน DoS เพิ่มเติม และมีการเปิดเผย CVE-2025-55183·55184·67779

ผู้รายงาน

• Andrew MacPherson (AndrewMohawk) — รายงานการเปิดเผยซอร์สโค้ด
• RyotaK (GMO Flatt Security Inc) และ Shinsaku Nomura (Bitforest Co., Ltd.) — รายงานช่องโหว่การปฏิเสธการให้บริการ

[GN⁺]

ความเห็นจาก Hacker News

• React Server Components (RSC) ให้ความรู้สึกอึดอัดอยู่เสมอ
  เพราะแค่ดูโค้ด JavaScript อย่างเดียวก็แยกได้ยากว่าส่วนไหน รันบนไคลเอนต์ และส่วนไหน รันบนเซิร์ฟเวอร์
  แถมการทำสิ่งนี้ยังต้องพึ่ง กลไก RPC แบบ serialization ที่ซับซ้อนลึกลงไป ซึ่งไม่โปร่งใสสำหรับนักพัฒนา และเป็นจุดที่เพิ่มความเสี่ยงด้านช่องโหว่ความปลอดภัย

  • สมัย NextJS pages router ผมชอบที่เส้นแบ่งระหว่างโค้ดฝั่งเซิร์ฟเวอร์กับฝั่งไคลเอนต์ชัดเจน
    แต่พอเปลี่ยนมาใช้ app router ก็เริ่มสับสน เพราะโค้ดอาจรันได้ทั้งสองฝั่ง ทำให้ object อย่าง Headers ไม่ได้มีอยู่เสมอ และยากจะรู้ว่า อะไรทำงานอยู่ที่ไหน
  • ตอนเข้าทีมใหม่แล้วเห็นว่าใช้ Next ผมถามว่า “มีใครอธิบายได้ไหมว่านี่ทำงานยังไง” แต่ไม่มีใครอธิบายได้ชัดเจน
    เวลา React+Next ทำงานได้ดีมันเหมือนเวทมนตร์ แต่พอทำงานเป็นทีม ปัญหาคือ ความสามารถในการคาดเดาได้ ค่อย ๆ หายไป
  • เพราะงั้นผมเลยเป็นแฟนของ Inertia.js Inertia.js เชื่อมต่อแบ็กเอนด์ MVC แบบดั้งเดิมอย่าง Laravel, Rails, Django เข้ากับเครื่องมือฟรอนต์เอนด์อย่าง React, Vue, Svelte ได้อย่างเป็นธรรมชาติ
    บทบาทแต่ละส่วนชัดเจน งานเรียบง่าย และผมคิดว่านี่เป็นตัวเลือกที่ปลอดภัยที่สุดสำหรับโปรเจกต์ส่วนใหญ่
  • ดูเหมือนว่า RSC และ SSR จะถูกนำไปใช้มากเกินไป
    ถ้าเป็นหน้า landing page หรือหน้า marketing SSR ก็มีประโยชน์ แต่สำหรับแอปอย่างแดชบอร์ด SaaS ทั่วไป แทบไม่ได้ประโยชน์อะไรเลย เมื่อเทียบกับความซับซ้อนที่เพิ่มขึ้น
  • เลยสงสัยว่าเฟรมเวิร์กอื่น ๆ อย่าง Angular, SvelteKit, Nuxt จะเปิดรับช่องโหว่แบบนี้มากน้อยแค่ไหน
    เป็นเพราะ React ดังเลยถูกจับตามองมากกว่า หรือว่ามันมีความเสี่ยงเชิงโครงสร้างมากกว่ากันแน่

• สัปดาห์ก่อนผมลองดู RSC แล้วพบว่า ซับซ้อน มากและแทบไม่มีเอกสารเลย
  React บอกว่ายังเป็นฟีเจอร์เชิงทดลอง แต่ NextJS กลับเอาไปปล่อยใช้อย่างกว้างขวางแล้ว
  คิดว่าน่าจะมีปัญหาความปลอดภัยออกมาอีกในอนาคต และ ระบบ build ของ Next ก็ซับซ้อนเกินไปจนดีบักยังยาก
  ต้นทุนสูงเกินไปเมื่อเทียบกับประโยชน์ที่ได้

  • ก่อนหน้านี้ก็มีคนบ่นมานานว่า Next ชอบเอา “ฟีเจอร์ React ที่ยังไม่พร้อมสำหรับ production” มาห่อว่าเป็นของใหม่ล่าสุด
    นั่นก็เป็นเหตุผลที่ผมเลิกใช้ Next เพราะ ภาระทางความคิด สูงเกินไปแต่ได้กลับมาไม่คุ้ม
  • React มีปัญหาเรื่อง เอกสารไม่เพียงพอ มานานแล้ว
    ไม่ใช่แค่ RSC แต่โดยรวมก็ขาดไกด์ที่ชัดเจนมานาน และยังไม่ยอมรับเครื่องมืออย่าง CRA อย่างเป็นทางการ
    ตอนนี้เอกสารของ useEffect ดีขึ้นแล้วก็จริง แต่ช้าเกินไป
    แม้จะเป็นปี 2025 แล้วและยังใช้งานกันจริงอยู่ แต่ก็ยังขาด เอกสารที่ชัดเจน

• แก่นของ SPA คือ “ส่งทั้งแอปไปที่ฝั่งไคลเอนต์ แล้วคุยกับเซิร์ฟเวอร์ด้วย ข้อมูลเท่านั้น”

  • แต่ตอนนี้ฝั่ง C# กลับนิยม Blazor Server
    มันเหมือน .aspx Web Forms สมัยก่อนที่ทุกการคลิกและการพิมพ์ถูกส่งกลับไปที่เซิร์ฟเวอร์ แล้วค่อยส่ง DOM ที่เปลี่ยนแล้วกลับลงมา
    เรียกได้ว่าเป็นการย้อนกลับไปวิธีเดิม เลยรู้สึกแปลก ๆ
  • สุดท้ายแล้วนักพัฒนาจำนวนมากก็กลับมาตระหนักถึงเหตุผลของ server-side rendering และหวนกลับไปใช้เฟรมเวิร์กฟูลสแตกอย่าง PHP, Rails, Spring
  • แต่ทุกวันนี้คนกลับใช้ไลบรารีอย่าง React มาสร้าง เว็บไซต์แบบสแตติก กันมากขึ้น ซึ่งทั้งช้ากว่าและซับซ้อนกว่าการใช้ template engine + JS แบบง่าย ๆ
    น่าเสียดายที่ความรู้สึกว่า “ควรเลือกเครื่องมือให้เหมาะกับงาน” ดูจะหายไป
  • แน่นอนว่า RSC ไม่ได้มีไว้สำหรับ SPA ล้วน ๆ อยู่แล้ว แต่มันเป็นแนวทางที่มีเป้าหมายต่างออกไป

• ในประกาศด้านความปลอดภัยครั้งนี้ ประโยคที่สะดุดตาที่สุดคือ “เมื่อพบ CVE ระดับร้ายแรง ก็มักจะมีช่องโหว่ต่อเนื่องถูกเปิดเผยตามมา”
  มันทำให้รู้สึกไม่สบายใจ เหมือนพยายาม หาเหตุผลรองรับ CVE ก่อนจะอธิบายขอบเขต ผลกระทบ หรือวิธีบรรเทาปัญหาด้วยซ้ำ

  • แต่ก็มีคนมองว่า “นั่นไม่ใช่การหาเหตุผล แต่เป็นแค่ คำอธิบาย ในสิ่งที่คนส่วนใหญ่อยากรู้ก่อนเป็นอันดับแรก”
  • มีการบอกว่าปรับถ้อยคำตาม feedback แล้ว → ลิงก์ PR ที่แก้ไข
  • บางคนเรียกสิ่งนี้ว่า การจัดการการรับรู้ (perception management)
    บทความวิกิที่เกี่ยวข้อง
  • บางมุมมองเห็นว่าเรื่องนี้มี ผลประโยชน์ด้านอาชีพ เข้ามาเกี่ยวข้องด้วย
  • บางคนบอกว่า “นี่อ่านแล้วเหมือนบทความที่ทีมการตลาดของ Vercel เขียน”

• เมื่อ 15 ปีก่อน Opa ก็เคยลองแนวคิดคล้ายกันมาแล้ว
  มันแยกโค้ดไคลเอนต์กับเซิร์ฟเวอร์ให้อัตโนมัติ และนำ syntax คล้าย JSX มาใช้
  แต่เมื่อพยายามเสริมการวิเคราะห์ด้านความปลอดภัย คอมไพเลอร์ก็พองโตมากขึ้นเรื่อย ๆ และสุดท้ายก็ทำให้ตระหนักว่าการแยกส่วนให้ชัดเจนสำคัญกว่าคอนเซปต์แอปเดียว
  สักวันหนึ่ง LLM อาจสร้างโค้ดแบบนี้ให้อัตโนมัติได้ แต่ตอนนี้ผมยังคิดว่าโครงสร้างที่เรียบง่ายดีกว่า

  • จริง ๆ แล้วช่องโหว่ของ RSC ไม่ได้มาจากการแยกโค้ดเป็นหลัก แต่เกิดจาก ลักษณะเชิงไดนามิกของกระบวนการ serialize/deserialize
    ตอนนี้กำลังมีแพตช์เพื่อป้องกันปัญหาอย่าง prototype pollution ของ JS, toString ของฟังก์ชัน, การ override Promise เป็นต้น
    RSC แยกสภาพแวดล้อมด้วย การตรวจสอบแบบสแตติก อย่าง import "server-only" หรือ import "client-only" ดังนั้นในเชิงโครงสร้างถือว่าเป็นแนวทางที่ปลอดภัย
  • ยังมีโปรเจกต์ชื่อ Electric Clojure ที่มีไอเดียคล้ายกัน → ลิงก์
  • และถ้าจะอ้างอิงให้ครบ Ocsigen Eliom ก็ทดลองแนวคิดนี้ก่อน Opa อีก

• React เคยดีกว่าตอนที่มันเล็กและเรียบง่าย ทำหน้าที่เป็น View ของ MVC
  ตอนนี้มันมีความสามารถเยอะเกินไปจนรู้สึกว่า ตัวใหญ่เทอะทะ

  • แต่ RSC เป็นไลบรารีแยกต่างหาก จึงไม่ได้รวมอยู่ใน React install พื้นฐาน
  • ถ้าอยากย้อนกลับไปเวอร์ชันเก่า ก็แค่ git checkout v15.0.0

• RSC ไม่ควรถูกสร้างขึ้นมาตั้งแต่แรก
  แอปส่วนใหญ่แค่เรนเดอร์ HTML จากฝั่งเซิร์ฟเวอร์ก็เพียงพอแล้ว และกรณีที่ต้องใช้ SPA จริง ๆ ก็มีน้อยมาก
  RSC มีแต่เพิ่ม ความซับซ้อนและช่องโหว่ด้านความปลอดภัย

  • เห็นด้วย แต่ ecosystem ที่ขับเคลื่อนด้วย bootcamp หรือเงินทุน VC ก็ยังดันแนวทางนี้ต่อไป
    โปรเจกต์อย่าง Bun, Vercel กำลังขาย ภาพฝัน ของ “JS utopia ที่ทุกอย่างทำงานได้อย่างสมบูรณ์” เลยคิดว่ากระแสนี้คงไม่หายไปง่าย ๆ

• ก่อนหน้านี้ผมเคยถกเถียงกับ Dan Abramov บน X เรื่อง RSC
  เขาบอกว่ามันเป็นฟีเจอร์นวัตกรรม แต่ผมบอกว่ามันคือ “ปืนที่ยิงเท้าตัวเอง” แล้วสุดท้ายความจริงก็ออกมาแบบนั้น

  • ส่วนตัวผมเคยสร้างแอปด้วย RSC และยังชอบแนวทางนี้อยู่
    แต่เราประเมินความเป็นไปได้ของบั๊กในระดับโปรโตคอลต่ำเกินไป ช่องโหว่ครั้งนี้โฟกัสที่ serialization protocol โดยตรง
    ตอนนี้ฝั่ง security community เพิ่งเริ่มลงไปตรวจลึก ๆ เลยรู้สึกว่าทีมน่าจะรับมือเร็วกว่านี้
  • ระบบที่ประสบความสำเร็จมักลงเอยด้วยการ ขยายตัวเกินขนาด จนกลายเป็นสัตว์ประหลาด
    React ก็จากไลบรารีเรนเดอร์ง่าย ๆ กลายเป็น runtime ที่ทำให้ความซับซ้อนพุ่งขึ้นมาก
  • ส่วนตัวผมไม่ได้รู้สึกว่าแนวทางของ Dan ยอดเยี่ยมอะไรนัก
    ตรงกันข้าม Vue และ Vite ดูออกแบบได้ประณีตกว่ามาก → เว็บไซต์ส่วนตัวของ Evan You
  • แน่นอนว่าไอเดียส่วนใหญ่ย่อมล้มเหลวอยู่แล้ว ดังนั้นก็ควรระวังท่าทีที่เอาแต่โจมตีอย่างเดียว
    บางครั้ง ความพยายามที่กล้าหาญ ก็อาจกลายเป็นโฮมรันได้
  • ยังมีคอมเมนต์ให้กำลังใจว่า “บางทีคุณอาจจะเก่งกว่าก็ได้”

• ถ้า RSC คือความพยายามของฟรอนต์เอนด์ที่จะ กลืนแบ็กเอนด์ HTMX ก็คือด้านตรงข้าม
  HTMX รักษาเส้นแบ่งระหว่างไคลเอนต์กับเซิร์ฟเวอร์ไว้ จึงปลอดภัยกว่าทางฝั่งแบ็กเอนด์ แต่ฝั่งฟรอนต์เอนด์ยังมีความเสี่ยง XSS

  • แต่ HTMX ก็แก้ปัญหา XSS ไปแล้วด้วย auto-escaping ของ template engine
    บทความที่เกี่ยวข้อง

• ทีม Next ได้ประกาศอัปเดตความปลอดภัยใหม่ → NextJS Security Update 2025-12-11
  ส่งผลกระทบต่อเวอร์ชัน 14.x, 15.x, 16.x