Công bố lỗ hổng DoS và rò rỉ mã nguồn trong React Server Components

 (react.dev)
4 điểm bởi GN⁺ 2025-12-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong React Server Components mới phát hiện và công bố các lỗ hổng từ chối dịch vụ (DoS) và rò rỉ mã nguồn
  • Các lỗ hổng lần này không cho phép thực thi mã từ xa (RCE), nhưng vẫn tồn tại rủi ro làm gián đoạn máy chủ hoặc làm lộ mã
  • Các gói bị ảnh hưởng là react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack ở các phiên bản 19.0.0~19.2.2, còn các phiên bản đã vá là 19.0.3, 19.1.4, 19.2.3
  • Lỗ hổng DoS (CVE-2025-55184, CVE-2025-67779) có thể khiến máy chủ rơi vào vòng lặp vô hạn thông qua yêu cầu HTTP độc hại, còn lỗ hổng rò rỉ mã nguồn (CVE-2025-55183) có thể trả về một phần mã của hàm máy chủ
  • Nhóm React khuyến nghị nâng cấp ngay lập tức và giải thích rằng đợt công bố bổ sung này là một phần bình thường trong chu kỳ ứng phó bảo mật

Tổng quan về các lỗ hổng mới được công bố

  • Trong quá trình xác minh bản vá cho lỗ hổng nghiêm trọng được công bố tuần trước, các nhà nghiên cứu bảo mật đã phát hiện thêm hai lỗ hổng nữa
  • Các lỗ hổng mới không cho phép thực thi mã từ xa (RCE), và bản vá React2Shell hiện tại vẫn có hiệu lực
  • Các lỗ hổng mới được công bố gồm có
    • Từ chối dịch vụ (DoS) — CVE-2025-55184, CVE-2025-67779 (CVSS 7.5, mức nghiêm trọng cao)
    • Rò rỉ mã nguồn — CVE-2025-55183 (CVSS 5.3, mức nghiêm trọng trung bình)
  • Nhóm React khuyến nghị nâng cấp ngay lập tức

Tính chưa hoàn chỉnh của bản vá trước đó

  • Bản vá phát hành tuần trước trong các phiên bản 19.0.2, 19.1.3, 19.2.2 là chưa hoàn chỉnh, nên cần cập nhật lại
  • Bản sửa lỗi đầy đủ được đưa vào các phiên bản 19.0.3, 19.1.4, 19.2.3
  • Cần làm theo hướng dẫn cập nhật trong bài viết trước
  • Sau khi hoàn tất phát hành bản sửa lỗi, sẽ công bố thêm chi tiết

Gói và phiên bản bị ảnh hưởng

  • Các lỗ hổng này tồn tại trong cùng gói và phiên bản với CVE-2025-55182
  • Phiên bản bị ảnh hưởng: 19.0.0~19.2.2
  • Các gói bị ảnh hưởng:
    • react-server-dom-webpack
    • react-server-dom-parcel
    • react-server-dom-turbopack
  • Phiên bản đã vá: 19.0.3, 19.1.4, 19.2.3
  • Các ứng dụng không dùng máy chủ hoặc không hỗ trợ React Server Components thì không bị ảnh hưởng

Mô hình phổ biến của việc công bố lỗ hổng tiếp theo

  • Sau khi một CVE nghiêm trọng được công bố, trong quá trình phân tích bổ sung các đường mã liên quan, thường sẽ phát hiện thêm các lỗ hổng tiếp theo
  • Bài viết nhắc đến trường hợp nhiều CVE bổ sung được báo cáo sau Log4Shell như một ví dụ
  • Những công bố bổ sung như vậy có nghĩa là quy trình ứng phó bảo mật đang hoạt động bình thường

Framework và bundler bị ảnh hưởng

  • Các framework và bundler sau đây bao gồm hoặc phụ thuộc vào các gói React dễ bị tấn công
    • next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, rwsdk
  • Cần làm theo hướng dẫn cập nhật trong bài viết trước

Biện pháp giảm thiểu từ nhà cung cấp hosting

  • Đã phối hợp với nhiều nhà cung cấp hosting để áp dụng các biện pháp giảm thiểu tạm thời
  • Tuy nhiên, không nên dựa vào các biện pháp này và cần cập nhật ngay lập tức

Hướng dẫn liên quan đến React Native

  • Người chỉ sử dụng React Native không cần thêm hành động nào
  • Trong môi trường monorepo, chỉ cần cập nhật các gói sau
    • react-server-dom-webpack
    • react-server-dom-parcel
    • react-server-dom-turbopack
  • Không cần cập nhật react và react-dom
  • Chi tiết liên quan có thể tham khảo issue GitHub của React Native

Mức nghiêm trọng cao: từ chối dịch vụ (DoS)

  • CVE-2025-55184, CVE-2025-67779, CVSS 7.5
  • Khi một yêu cầu HTTP độc hại được gửi tới endpoint hàm máy chủ React, quá trình giải tuần tự hóa có thể gây ra vòng lặp vô hạn
  • Tiến trình máy chủ có thể bị gián đoạn và chiếm dụng CPU quá mức
  • Ngay cả khi không trực tiếp triển khai endpoint hàm máy chủ, ứng dụng hỗ trợ React Server Components vẫn có thể dễ bị ảnh hưởng
  • Bản vá phát hành hôm nay giải quyết vấn đề bằng cách ngăn vòng lặp vô hạn
  • Bản sửa lỗi ban đầu chưa hoàn chỉnh nên đã được bổ sung bằng lỗ hổng tiếp theo (CVE-2025-67779)

Mức nghiêm trọng trung bình: rò rỉ mã nguồn

  • CVE-2025-55183, CVSS 5.3
  • Một yêu cầu HTTP độc hại có thể khiến một phần mã nguồn của hàm máy chủ bị trả về
  • Điều này xảy ra khi hàm máy chủ làm lộ đối số chuỗi một cách tường minh hoặc ngầm định
  • Trong mã ví dụ, các giá trị bí mật được hardcode như khóa kết nối cơ sở dữ liệu có thể bị lộ
  • Bản vá giải quyết vấn đề bằng cách ngăn việc chuyển mã nguồn của hàm máy chủ thành chuỗi
  • Phạm vi rò rỉ chỉ giới hạn trong mã nội bộ của hàm máy chủ, còn bí mật thời gian chạy (process.env.SECRET v.v.) thì không bị ảnh hưởng
  • Cần xác minh dựa trên production bundle

Dòng thời gian

  • Ngày 3 tháng 12: Andrew MacPherson báo cáo vấn đề rò rỉ mã cho Vercel và Meta Bug Bounty
  • Ngày 4 tháng 12: RyotaK báo cáo lỗ hổng DoS
  • Ngày 6 tháng 12: Nhóm React xác nhận hai vấn đề và bắt đầu điều tra
  • Ngày 7 tháng 12: Soạn bản sửa lỗi ban đầu và lập kế hoạch xác minh
  • Ngày 8 tháng 12: Thông báo cho các nhà cung cấp hosting và các dự án mã nguồn mở
  • Ngày 10 tháng 12: Áp dụng biện pháp giảm thiểu và hoàn tất xác minh bản vá
  • Ngày 11 tháng 12: Shinsaku Nomura báo cáo thêm lỗ hổng DoS, công bố CVE-2025-55183·55184·67779

Người báo cáo

  • Andrew MacPherson (AndrewMohawk) — báo cáo rò rỉ mã nguồn
  • RyotaK (GMO Flatt Security Inc) và Shinsaku Nomura (Bitforest Co., Ltd.) — báo cáo lỗ hổng từ chối dịch vụ

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-12-13
Ý kiến trên Hacker News

  • React Server Components (RSC) từ trước đến nay luôn tạo cảm giác khó chịu
    Vì chỉ nhìn mã JavaScript thì rất khó phân biệt phần chạy ở client với phần chạy ở server
    Hơn nữa, để hiện thực hóa điều này cần một cơ chế RPC tuần tự hóa khá sâu, vốn thiếu minh bạch với lập trình viên và làm tăng nguy cơ lỗ hổng bảo mật

    • Thời NextJS pages router trước đây khá ổn vì ranh giới giữa mã server và client rất rõ ràng
      Nhưng khi chuyển sang app router thì mọi thứ trở nên rối rắm. Vì mã có thể chạy ở cả hai phía nên các đối tượng như Headers không phải lúc nào cũng tồn tại, khiến rất khó biết cái gì đang chạy ở đâu
    • Khi vào một team mới thấy họ dùng Next, tôi đã hỏi “có ai biết thứ này hoạt động thế nào không?”, nhưng chẳng ai giải thích rõ ràng được
      React+Next khi chạy tốt thì như phép màu, nhưng khi làm việc theo team thì vấn đề là tính dự đoán được ngày càng biến mất
    • Vì vậy tôi là fan của Inertia.js. Inertia.js kết nối rất tự nhiên giữa các backend MVC truyền thống như Laravel, Rails, Django với các công cụ frontend như React, Vue, Svelte
      Vai trò rõ ràng, công việc đơn giản, và tôi nghĩ đây là lựa chọn an toàn nhất cho phần lớn dự án
    • Có vẻ như RSC và SSR đang bị lạm dụng quá mức
      Với landing page hay trang marketing thì SSR hữu ích, nhưng với các ứng dụng kiểu dashboard SaaS thông thường thì gần như không có lợi ích gì so với độ phức tạp phải đánh đổi
    • Tôi cũng tò mò không biết các framework khác như Angular, SvelteKit, Nuxt đang phơi nhiễm đến mức nào với các lỗ hổng kiểu này
      Không rõ là vì React quá phổ biến nên bị soi nhiều hơn, hay bản thân cấu trúc của nó vốn rủi ro hơn

  • Tuần trước tôi có xem qua RSC, và độ phức tạp của nó quá cao trong khi tài liệu gần như không có
    React thì nói đây vẫn là tính năng thử nghiệm, nhưng NextJS lại đã triển khai rất rộng rãi
    Có vẻ rồi sẽ còn xuất hiện thêm nhiều vấn đề bảo mật nữa, và hệ thống build của Next thì phức tạp quá mức đến mức ngay cả debug cũng khó
    Chi phí bỏ ra quá lớn so với lợi ích nhận được

    • Từ trước đã có phàn nàn rằng Next luôn đóng gói “các tính năng React chưa sẵn sàng cho production” như thể đó là tính năng mới nhất
      Vì vậy tôi cũng đã rời bỏ Next. Gánh nặng nhận thức quá lớn mà thu lại chẳng được bao nhiêu
    • React từ lâu đã có vấn đề thiếu tài liệu
      Không chỉ RSC mà nhìn chung các hướng dẫn rõ ràng đều ra rất chậm, và họ cũng không chính thức công nhận các công cụ như CRA
      Mãi đến gần đây tài liệu về useEffect mới tốt hơn, nhưng đã quá muộn
      Giờ đã là năm 2025 mà tôi vẫn dùng nó trong công việc hằng ngày, nhưng tài liệu hóa rõ ràng vẫn còn thiếu

  • Cốt lõi của SPA là “đẩy toàn bộ ứng dụng xuống client và chỉ trao đổi dữ liệu với server”

    • Thế nhưng hiện tại trong hệ C# thì Blazor Server lại đang thịnh hành
      Giống .aspx Web Forms ngày xưa, mọi cú click và nhập liệu đều được gửi về server, rồi DOM đã thay đổi lại được trả xuống
      Thực chất là quay lại cách làm cũ nên khá khó hiểu
    • Cuối cùng nhiều lập trình viên lại nhận ra lý do tồn tại của server-side rendering, rồi quay về với các framework full-stack như PHP, Rails, Spring
    • Nhưng dạo này người ta lại thường dùng những thư viện như React để làm trang tĩnh, vừa chậm hơn vừa phức tạp hơn so với tổ hợp template engine + JS đơn giản
      Thật tiếc khi “cảm giác chọn đúng công cụ” dường như đã biến mất
    • Tất nhiên, RSC không phải dành cho SPA thuần túy. Nó là một cách tiếp cận với mục tiêu khác

  • Trong thông báo bảo mật lần này, câu gây chú ý nhất là “khi phát hiện một CVE nghiêm trọng thì thường sẽ lộ ra thêm các lỗ hổng tiếp theo”
    Trước cả khi giải thích phạm vi vấn đề, tác động hay cách giảm thiểu, họ đã như thể đang cố biện minh cho CVE, nên khá đáng lo

    • Nhưng có người cho rằng “đó không phải là biện minh, mà chỉ là giải thích cho điều mà mọi người tò mò đầu tiên”
    • Họ nói đã chỉnh lại câu chữ sau khi nhận phản hồi → liên kết PR đã sửa
    • Có người gọi đây là quản lý nhận thức (perception management)
      Bài wiki liên quan
    • Cũng có góc nhìn cho rằng vụ việc này gắn với lợi ích nghề nghiệp
    • Có người nói “bài này trông như do team marketing của Vercel viết”

  • 15 năm trước, Opa đã từng thử một hướng đi tương tự
    Nó tự động tách mã client và server, đồng thời đưa vào cú pháp tương tự JSX
    Nhưng khi tăng cường phân tích bảo mật thì compiler trở nên khổng lồ, và cuối cùng người ta nhận ra tầm quan trọng của việc tách biệt rõ ràng hơn là khái niệm một ứng dụng duy nhất
    Có thể một ngày nào đó LLM sẽ tự động sinh ra kiểu mã này, nhưng hiện tại tôi vẫn nghĩ cấu trúc đơn giản là tốt hơn

    • Trên thực tế, lỗ hổng của RSC không hẳn đến từ việc chia tách mã mà đến từ đặc tính động của quá trình serialize/deserialize
      Hiện đang có các bản vá để ngăn những vấn đề như ô nhiễm prototype trong JS, hàm toString, ghi đè Promise
      RSC phân biệt môi trường bằng các cơ chế kiểm tra tĩnh như import "server-only" hoặc import "client-only", nên về mặt cấu trúc đây vẫn là một cách tiếp cận an toàn
    • Cũng có một dự án với ý tưởng tương tự là Electric Clojure → liên kết
    • Nhân tiện, Ocsigen Eliom đã thử khái niệm này trước cả Opa

  • React vốn hay nhất khi còn nhỏ gọn, đơn giản và chỉ đóng vai trò View trong MVC
    Giờ thì nó nhồi quá nhiều tính năng nên có cảm giác phình to quá mức

    • Tuy nhiên, RSC là thư viện riêng nên không nằm trong bản cài React mặc định
    • Nếu muốn quay về phiên bản cũ thì chỉ cần git checkout v15.0.0

  • RSC lẽ ra không nên tồn tại ngay từ đầu
    Phần lớn ứng dụng chỉ cần render HTML ở server là đủ, còn trường hợp thực sự cần SPA thì rất ít
    RSC chỉ làm tăng độ phức tạp và lỗ hổng bảo mật

    • Đồng ý. Nhưng các bootcamp và hệ sinh thái được vốn VC hậu thuẫn vẫn đang tiếp tục đẩy theo hướng này
      Những dự án như Bun, Vercel đang bán ra ảo tưởng về một “JS utopia nơi mọi thứ hoạt động hoàn hảo”, nên có lẽ xu hướng này sẽ không sớm biến mất

  • Trước đây tôi từng tranh luận với Dan Abramov trên X về RSC
    Anh ấy gọi đó là tính năng đột phá, còn tôi thì bảo nó là “khẩu súng tự bắn vào chân mình”. Rốt cuộc thực tế đã diễn ra đúng như vậy

    • Cá nhân tôi đã thử xây ứng dụng bằng RSC và vẫn thích cách làm này
      Chỉ là tôi đã đánh giá thấp khả năng xuất hiện lỗi ở cấp độ giao thức. Lỗ hổng lần này tập trung vào giao thức tuần tự hóa
      Cộng đồng bảo mật giờ mới bắt đầu đào sâu vào nó, nên tôi ước team đã phản ứng sớm hơn
    • Một hệ thống thành công cuối cùng rất dễ biến thành quái vật vì mở rộng quá mức
      React cũng đã chuyển từ một thư viện render đơn giản thành một runtime, và độ phức tạp bùng nổ từ đó
    • Cá nhân tôi không thấy cách tiếp cận của Dan là quá xuất sắc
      Trong khi đó Vue và Vite theo tôi có thiết kế tinh tế hơn nhiều → trang cá nhân của Evan You
    • Tất nhiên, phần lớn ý tưởng vốn dĩ sẽ thất bại, nên cũng cần tránh thái độ chỉ biết chỉ trích
      Đôi khi những thử nghiệm táo bạo lại trở thành cú home run
    • Cũng có bình luận động viên rằng “có khi bạn mới là người giỏi hơn”

  • Nếu RSC là nỗ lực để frontend nuốt chửng backend, thì HTMX là điều ngược lại
    HTMX giữ nguyên ranh giới client–server nên phía backend an toàn hơn, nhưng ở frontend thì vẫn có rủi ro XSS

    • Nhưng HTMX thực ra đã giải quyết vấn đề XSS bằng cơ chế escape tự động của template engine
      Bài viết liên quan

  • Team Next đã công bố bản cập nhật bảo mật mới → NextJS Security Update 2025-12-11
    Ảnh hưởng đến các phiên bản 14.x, 15.x, 16.x