Node.js vá lỗi HTTP/2: vì sao đóng một luồng có thể làm sập máy chủ?

Đợt cập nhật ngày 11/11 xử lý nhiều lỗi trong Node.js. Muốn đánh giá mức phơi nhiễm, đội vận hành cần biết kết nối HTTP/2 thực sự kết thúc ở đâu.

Node.js vá lỗi HTTP/2: vì sao đóng một luồng có thể làm sập máy chủ?

Ngày 11/11/2026, dự án Node.js phát hành bản vá bảo mật cho ba nhánh 22, 24 và 26. Một lỗi mức cao, CVE-2026-123863, nằm ở khâu dọn bộ nhớ khi phiên HTTP/2 kết thúc: máy chủ có thể dừng tiến trình khi kiểm tra trạng thái dọn dẹp thất bại. Để biết dịch vụ nào cần ưu tiên cập nhật, hãy lần theo kết nối từ người dùng qua lớp trung gian tới Node.js, thay vì chỉ nhìn biểu tượng HTTPS trên trình duyệt.

Vì sao kết thúc kết nối cũng là một bề mặt tấn công?

HTTP/2 cho phép nhiều yêu cầu và phản hồi đi qua các luồng riêng trên cùng một kết nối. Trong một cửa hàng trực tuyến giả định, trình duyệt có thể dùng chung kết nối để tải ảnh, lấy thông tin giỏ hàng và nhận nội dung trang. Hủy một luồng tải ảnh không nhất thiết đóng kết nối hoặc dừng hai tác vụ còn lại. Phần mềm máy chủ phải tách trạng thái của từng luồng khỏi trạng thái của cả phiên.

Thách thức xuất hiện khi một luồng bị xóa trong lúc công việc liên quan chưa hoàn tất. Bộ nhớ chứa thông tin đầu yêu cầu có thể vẫn gắn với một cấu trúc mà phần xử lý luồng đã bỏ qua. Theo thông báo bảo mật của dự án, CVE-2026-123863 có thể khiến bước kiểm tra bộ nhớ lúc hủy phiên phát hiện một giá trị trái với điều chương trình kỳ vọng. Nhật ký bản phát hành mô tả bản sửa là giải phóng phần đầu khi luồng bị loại bỏ. Tác động được công bố của lỗi này là làm gián đoạn dịch vụ; thông báo đó không phải bằng chứng rằng một hệ thống cụ thể đã bị khai thác.

Nhóm Node.js còn công bố các lỗi HTTP/2 khác. Chẳng hạn, CVE-2026-123874 liên quan tới luồng gửi tệp bị đặt lại khi thao tác ghi còn chờ. Với lỗi dùng bộ nhớ sau khi đã giải phóng, câu hỏi là phần nào còn giữ tham chiếu đến tài nguyên và thao tác đó kết thúc lúc nào. Hai lỗi có thể cùng biểu hiện quanh thời điểm đóng luồng nhưng khác cơ chế và hậu quả. Đội vận hành nên tra từng mục thay vì dùng mã của một lỗi để mô tả toàn bộ đợt vá.

Đừng dùng giao thức trình duyệt để suy ra giao thức ở máy chủ

Một dịch vụ có thể đặt bộ cân bằng tải trước cụm Node.js. Bộ cân bằng tải nhận kết nối HTTP/2 từ trình duyệt, sau đó mở một kết nối HTTP/1.1 riêng tới ứng dụng. Trong cấu hình đó, trình duyệt báo HTTP/2 vẫn chưa chứng minh tiến trình Node trực tiếp nhận và giải mã khung HTTP/2 của khách. Ngược lại, một tuyến gRPC hoặc cổng nội bộ có thể duy trì HTTP/2 tới ứng dụng dù phần web chính đi qua một đường khác.

Hãy lập sơ đồ cho từng cổng và chiều kết nối. Kiểm tra cấu hình giao thức từ bộ cân bằng tải đến ứng dụng, cơ chế chọn giao thức trong TLS và các điểm phục vụ HTTP/2 trực tiếp. Cần xem cả mạng nội bộ nếu ứng dụng có thể nhận lưu lượng từ hệ thống khác. Một dịch vụ đã chuyển sang HTTP/1.1 trên một tuyến vẫn có thể phơi nhiễm với các lỗi khác trong đợt cập nhật vì bản phát hành còn sửa thành phần HTTPS, TLS và mô hình quyền.

Đổi phiên bản chạy, rồi kiểm tra cả lúc người dùng hủy yêu cầu

Các bản phát hành vá tương ứng là 22.23.5, 24.22.3 và 26.13.1. Nhóm dùng container cần cập nhật phiên bản runtime trong ảnh nền, dựng lại ảnh và thay các bản đang chạy. Sửa tệp khóa phụ thuộc của dự án không tự thay tệp thực thi Node.js nằm trong ảnh. Ứng dụng trên nền tảng quản lý cũng cần đối chiếu phiên bản thực tế ở phiên bản triển khai, vì máy phát triển và môi trường chạy có thể dùng hai cấu hình khác nhau.

Trong môi trường thử nghiệm, ngoài luồng yêu cầu hoàn thành bình thường, nên kiểm tra tình huống ngắt tải giữa chừng và đóng kết nối khi còn yêu cầu khác. Với dịch vụ phát tệp, theo dõi tỷ lệ yêu cầu lỗi và số lần tiến trình phải khởi động lại. Sau khi triển khai thử trên một phần tải, kiểm tra cả số phiên bản đang phục vụ lẫn các chỉ số như bộ nhớ và độ trễ. Một bộ kiểm tra sức khỏe trả lời tốt ở thời điểm không tải chưa cho biết tiến trình hoạt động ổn định khi liên tục có phiên mở và đóng.

Chỉ số nào giúp biết việc vá đã hoàn thành?

Mục tiêu là biết những tiến trình nào còn mang phiên bản cũ, ở tuyến nào, và ai chịu trách nhiệm thay chúng. Một bản cập nhật thành công trên máy chủ đầu tiên chưa bảo vệ các bản sao còn lại, tác vụ chạy theo lịch hoặc bản triển khai đang chờ khôi phục. Đội vận hành có thể dùng danh sách phiên bản ở từng môi trường để phát hiện tình trạng một cụm tưởng đã vá nhưng vẫn khởi tạo bản sao từ ảnh cũ.

Nếu cần giảm phơi nhiễm trước lúc triển khai, giới hạn những tuyến đưa HTTP/2 trực tiếp vào dịch vụ có thể hữu ích sau khi kiểm tra phụ thuộc. Đổi giao thức tùy tiện có thể làm hỏng các hệ thống dùng gRPC hoặc tạo thêm sự cố. Giải pháp lâu dài vẫn là cập nhật đúng nhánh và xác minh từ tiến trình đang chạy. Đợt vá này nhắc đội phát triển dành chỗ trong kiểm thử cho tình huống khách bỏ dở thao tác, vì đó cũng là một phần bình thường của giao tiếp mạng.

Nguồn: Thông báo bảo mật ngày 11/11/2026 của dự án Node.js và nhật ký ba phiên bản được dẫn trong bài.

Ảnh minh họa: Tủ máy chủ, ảnh minh họa; không phải hệ thống bị ảnh hưởng đã được xác định. CSIRO qua Wikimedia Commons, CC BY 3.0.

Chia sẻ