Một luồng dữ liệu nén có thể trở thành điểm khởi đầu cho việc thực thi mã trái phép trên máy chủ. Với Node2Shell, các nhà nghiên cứu đã chứng minh khả năng khai thác lỗ hổng trong bộ giải mã Brotli của Node.js trên bản dựng chính thức, đặt ra yêu cầu rà soát và cập nhật môi trường thực thi ứng dụng trong doanh nghiệp.
Được theo dõi với mã CVE-2026-111497, lỗ hổng liên quan đến lỗi ghi ngoài giới hạn bộ đệm trong bộ giải mã Brotli tích hợp trong Node.js. Dự án Node.js phân loại lỗi ở mức cao và đã phát hành bản cập nhật bảo mật ngày 21/10/2026 cho các nhánh 22.x, 24.x và 26.x.
Điểm đáng chú ý là rủi ro nằm ở lớp runtime bên dưới ứng dụng. Vì vậy, ngay cả khi mã nguồn JavaScript không có lỗi rõ ràng, ứng dụng vẫn có thể phơi nhiễm nếu sử dụng phiên bản Node.js bị ảnh hưởng và giải nén dữ liệu Brotli do kẻ tấn công kiểm soát.
Từ lỗi giải nén đến khả năng thực thi mã từ xa
Brotli được sử dụng để giảm kích thước dữ liệu truyền qua HTTP. Khi tiếp nhận nội dung nén, ứng dụng cần giải mã dữ liệu trước khi phân tích hoặc xử lý nghiệp vụ.
Với CVE-2026-111497, một luồng Brotli được tạo đặc biệt có thể khiến bộ giải mã xử lý dữ liệu trong trạng thái không hợp lệ, dẫn đến ghi ngoài vùng nhớ được cấp phát. Lỗi an toàn bộ nhớ này mở ra khả năng làm gián đoạn tiến trình hoặc thực thi mã trong những điều kiện khai thác phù hợp.
Trong nghiên cứu mang tên Node2Shell, các nhà nghiên cứu bảo mật đã thực thi thành công mã trên image Node.js 24.22.0 dành cho Linux arm64, không cần debugger hay bản dựng tùy chỉnh. Thử nghiệm cần nhiều lần thực hiện để thành công. Khi sử dụng phiên bản đã vá 24.22.1, cùng dữ liệu đầu vào bị từ chối và mã không được thực thi.
Kết quả cho thấy khả năng khai thác đã vượt khỏi giả thuyết kỹ thuật. Tuy nhiên, phạm vi thử nghiệm không đại diện cho mọi kiến trúc, phiên bản và cấu hình triển khai; mức độ phơi nhiễm vẫn cần được đánh giá trên từng hệ thống.
Bề mặt tấn công xuất hiện ở cả hai chiều trao đổi HTTP
Việc đánh giá Node2Shell không nên chỉ tập trung vào các yêu cầu gửi trực tiếp đến máy chủ. Dữ liệu không đáng tin cậy có thể tiếp cận bộ giải mã từ cả chiều nhận yêu cầu và chiều ứng dụng kết nối ra ngoài.
Đối với yêu cầu gửi tới ứng dụng, middleware có thể tự động giải nén phần thân HTTP trước khi dữ liệu được chuyển tới logic nghiệp vụ. Express 5 hỗ trợ xử lý Brotli trong các bộ phân tích như express.json(), express.urlencoded(), express.text() và express.raw().
Điều này khiến thứ tự xử lý trở nên quan trọng: dữ liệu có được giải nén trước khi xác thực hay không, middleware được áp dụng trên những endpoint nào và các endpoint đó có thể được truy cập từ đâu.
Đối với kết nối ra ngoài, ứng dụng có thể nhận phản hồi nén từ API, dịch vụ tích hợp hoặc nguồn nội dung bên ngoài. Nghiên cứu của Imperva đã kiểm tra cả đường tiếp nhận phản hồi Brotli qua fetch() tích hợp trong Node.js.
Do đó, chỉ chặn yêu cầu Brotli ở cổng vào chưa chắc đã bao phủ toàn bộ rủi ro. Doanh nghiệp cần theo dõi đường đi của dữ liệu đến bộ giải mã, thay vì chỉ kiểm tra ứng dụng có công khai trên Internet hay không.
Vì sao doanh nghiệp cần ưu tiên xử lý?
Node.js thường được sử dụng trong API, ứng dụng web, dịch vụ tích hợp và các tác vụ xử lý nền. Những thành phần này có thể nắm giữ thông tin kết nối cơ sở dữ liệu, khóa API hoặc quyền truy cập tới các dịch vụ nội bộ.
Nếu kẻ tấn công thực thi được mã trong tiến trình ứng dụng, tác động sẽ phụ thuộc vào quyền và tài nguyên mà tiến trình đó được cấp. Các rủi ro cần xem xét gồm:
- Lộ thông tin nhạy cảm: thông tin xác thực, cấu hình hoặc dữ liệu ứng dụng có quyền truy cập.
- Gián đoạn dịch vụ: tiến trình gặp sự cố, bị khởi động lại liên tục hoặc mất khả năng phục vụ.
- Can thiệp hoạt động ứng dụng: thực hiện thao tác trái phép trong phạm vi quyền của tài khoản dịch vụ.
- Mở rộng xâm nhập: tiếp cận hệ thống liên quan thông qua các kết nối và quyền sẵn có.
Đây là những kịch bản rủi ro cần đánh giá theo kiến trúc triển khai, không phải kết luận rằng mọi hệ thống sử dụng Node.js đều có thể bị chiếm quyền theo cùng một cách.
Cập nhật runtime là bước khắc phục trọng tâm
Các phiên bản khắc phục được phát hành gồm:
- Node.js 22.23.4 cho nhánh 22.x.
- Node.js 24.22.1 cho nhánh 24.x.
- Node.js 26.12.1 cho nhánh 26.x.
Doanh nghiệp cần nâng cấp lên các mốc này hoặc phiên bản mới hơn đã có bản sửa trong nhánh tương ứng. Với môi trường không còn được hỗ trợ, cần lập kế hoạch chuyển sang nhánh được duy trì bảo mật.
Quan trọng hơn, việc cập nhật phải được xác nhận tại môi trường thực sự vận hành ứng dụng. Nâng cấp Node.js trên máy chủ không đồng nghĩa runtime bên trong container đã thay đổi. Tương tự, chỉnh sửa phiên bản trong cấu hình build chưa bảo đảm các workload đang chạy đã được thay thế.
Đội ngũ kỹ thuật cần kiểm tra image, triển khai lại ứng dụng và xác minh phiên bản sau cập nhật. Chỉ cập nhật Express hoặc các gói npm riêng lẻ không thay thế việc vá bộ giải mã nằm trong Node.js.
Kết hợp vá lỗi với kiểm soát phơi nhiễm
Trong quá trình triển khai bản cập nhật, doanh nghiệp nên rà soát những đường xử lý Brotli từ nguồn không đáng tin cậy. Nếu cần giới hạn tạm thời việc tiếp nhận dữ liệu nén, thay đổi phải được kiểm thử với luồng nghiệp vụ thực tế để tránh ảnh hưởng dịch vụ.
WAF có thể hỗ trợ phát hiện và ngăn chặn các mẫu tấn công đã biết ở những luồng lưu lượng nằm trong phạm vi kiểm soát. Tuy nhiên, lớp bảo vệ này không thay thế bản vá và cần được đánh giá riêng đối với dữ liệu ứng dụng nhận từ kết nối ra ngoài.
Song song, cần tăng cường theo dõi lỗi giải nén, sự cố tiến trình và các hành vi bất thường như tạo tiến trình con, kết nối đến địa chỉ lạ hoặc truy cập dữ liệu ngoài dự kiến. Một lần ứng dụng gặp lỗi chưa đủ để xác nhận khai thác, nhưng là tín hiệu cần điều tra khi xuất hiện cùng những dấu hiệu đáng ngờ khác.
Áp dụng đặc quyền tối thiểu cho tài khoản dịch vụ, giới hạn secret và phân đoạn mạng cũng giúp giảm tác động nếu tiến trình ứng dụng bị kiểm soát.
Bảo vệ ứng dụng bắt đầu từ khả năng nhìn rõ hệ thống
Node2Shell cho thấy một khoảng trống thường bị bỏ sót trong quản lý lỗ hổng: doanh nghiệp có thể kiểm soát tốt mã nguồn nhưng chưa nắm đầy đủ runtime đang chạy trong từng máy chủ, container và dịch vụ tích hợp.
Theo góc nhìn của VNCS Global, xử lý hiệu quả cần kết nối ba yếu tố: xác định đúng tài sản bị ảnh hưởng, triển khai và xác minh bản vá, duy trì giám sát sau khắc phục. Đây cũng là cơ sở để đánh giá liệu hệ thống chỉ đang phơi nhiễm hay đã xuất hiện dấu hiệu xâm nhập cần điều tra.
Chủ động bảo vệ ứng dụng từ nền tảng vận hành. Kết nối với VNCS Global để rà soát mức độ phơi nhiễm và tăng cường khả năng phát hiện, ứng phó trước các mối đe dọa nhắm vào hệ thống doanh nghiệp.
