Ngày 3/12/2025, lỗ hổng CVE-2025-55182 trên React Server Components được công bố. Giới nghiên cứu đặt ngay cho nó cái tên React2Shell. Điểm nghiêm trọng là 10 trên thang mười, mức tuyệt đối. Mức đó dành cho lỗ hổng cho phép thực thi mã từ xa mà không cần bất kỳ thông tin xác thực nào. Gửi được yêu cầu là chiếm được máy chủ.
Lỗi nằm ở chỗ máy chủ tin dữ liệu gửi lên từ trình duyệt
Cách khai thác được mô tả khá gọn. Kẻ tấn công gửi một yêu cầu HTTP chứa dữ liệu dựng riêng tới một ứng dụng đang chạy React Server Components. Dữ liệu đó đi qua giao thức truyền thành phần mà React dùng để nối trình duyệt với máy chủ, rồi được giải tuần tự ở phía máy chủ. Khâu giải tuần tự không kiểm tra đủ, nên mã của kẻ tấn công chạy ngay trong môi trường thực thi của ứng dụng.
Các phiên bản bị ảnh hưởng là React từ 19.0.0 tới 19.2.0, cùng mọi khung ứng dụng dựng trên thành phần máy chủ của React. Bản vá nằm ở 19.0.1, 19.1.2 và 19.2.1. Ứng dụng dùng Next.js nằm gọn trong diện đó.
Tốc độ là điều đáng sợ nhất
Số liệu quan trắc từ nhiều hãng an ninh cho thấy khoảng cách từ công bố tới khai thác thật được tính bằng giờ. Cả trình quét tự động lẫn người ngồi gõ tay đều nhập cuộc gần như cùng lúc. Tới ngày 5/12, việc khai thác đã lan rộng.
Nhóm tình báo mối đe doạ của Google ghi nhận nhiều cụm tấn công khác nhau cùng dùng lỗ hổng này. Chiến dịch quan sát được rải từ cửa hậu, trình tải mã cho tới trình đào tiền mã hoá. Có cả công cụ tạo đường hầm để đi sâu vào mạng nội bộ. Cùng một lỗ hổng, nhiều bên khai thác theo mục tiêu riêng.
Phòng thủ tự gây ra sự cố thứ hai
Ngày 5/12/2025, Cloudflare gặp sự cố bắt đầu lúc 8 giờ 47 phút giờ quốc tế và kéo dài khoảng hai mươi lăm phút. Khoảng 28% lưu lượng HTTP mà hãng phục vụ bị ảnh hưởng. Nguyên nhân không phải một cuộc tấn công, mà là chính nỗ lực chặn React2Shell.
Bản tường trình của Cloudflare mô tả khá thẳng thắn. Để dò được các yêu cầu khai thác, hãng nâng kích thước bộ đệm đọc thân yêu cầu lên một megabyte, đúng bằng giới hạn mặc định của Next.js. Công cụ kiểm thử tường lửa ứng dụng nội bộ lại không chịu được mức đó. Đội vận hành thực hiện một thay đổi thứ hai để tắt nó đi, qua hệ thống cấu hình toàn cầu.
Hệ thống ấy không triển khai dần theo cụm. Nó lan ra toàn bộ đội máy chủ trong vài giây, và sai sót cũng lan theo đúng tốc độ đó. Áp lực thời gian rút gọn quy trình, quy trình rút gọn thì rủi ro tăng. Không có lối thoát dễ dàng nào cho tình huống này. Cách khả dĩ là dựng sẵn quy trình vá khẩn từ lúc chưa có gì cháy.
Vấn đề không nằm ở việc có dùng React hay không
React và các khung dựa trên nó được dùng rất rộng trong các đội phát triển web tại Việt Nam. Vấn đề thật không nằm ở việc có dùng hay không. Nó nằm ở việc có biết mình đang chạy phiên bản nào hay không. Rất nhiều dự án bàn giao xong rồi để đó, không ai theo dõi danh sách phụ thuộc và cũng không ai nhận phần cập nhật.
Với các đơn vị làm gia công phần mềm, câu hỏi còn khó hơn. Bạn đã bàn giao bao nhiêu dự án dùng React trong hai năm qua? Và còn cách nào liên lạc với khách hàng cũ để báo họ cập nhật không? Quy trình đó phải có sẵn, chứ không phải thứ nghĩ ra lúc lỗ hổng đã công bố.
Một điểm nữa khiến lỗ hổng loại này khó xử lý. Nó không nằm trong mã do đội phát triển viết ra, mà nằm trong thư viện nền. Công cụ soát mã nội bộ vì thế không bắt được. Chỉ công cụ đối chiếu danh sách phụ thuộc với cơ sở dữ liệu lỗ hổng mới thấy. Hai loại công cụ khác nhau, và nhiều nơi mới có loại thứ nhất.
Khoảng cách từ công bố tới khai thác giờ đo bằng giờ, nên phòng thủ không đo được bằng tuần. Biết mình đang chạy phiên bản nào là bước đầu tiên, và cũng là bước nhiều nơi bỏ qua.
