Tóm tắt nhanh
- Lỗi CVE-2026-111497 nằm trong bộ giải mã Brotli, có thể ghi vượt bộ đệm khi xử lý dữ liệu nén được tạo có chủ đích.
- Node.js xác nhận lỗ hổng ảnh hưởng các nhánh 22.x, 24.x và 26.x; bản vá tương ứng là 22.23.4, 24.22.1 và 26.12.1.
- Rủi ro không chỉ ở máy chủ nhận request: ứng dụng client hoặc microservice giải nén phản hồi HTTP độc hại cũng có thể phơi ra cùng lỗi.
- Quản trị viên cần vá đúng runtime, khởi động lại tiến trình và dựng lại container; cập nhật thư viện Brotli của hệ điều hành riêng lẻ không đảm bảo đã xử lý.
Một dữ liệu Brotli không hợp lệ có thể khiến bộ giải mã Node.js ghi tràn khỏi vùng nhớ nội bộ 8 byte. Node.js đã phát hành bản vá cho CVE-2026-111497, nhưng điểm khó với đội vận hành là Brotli có thể được đóng gói bên trong runtime hoặc thư viện ứng dụng, nên cập nhật một gói hệ điều hành chưa chắc chạm tới thành phần đang chạy.
Lỗi nằm ở cách bộ giải mã xử lý luồng dữ liệu sai định dạng
Brotli là thuật toán nén không mất dữ liệu, thường được dùng để giảm kích thước nội dung web như HTML, CSS và JavaScript. Ứng dụng phải giải nén nội dung trước khi xử lý; chính bước đó trở thành điểm rủi ro nếu dữ liệu được tạo để khai thác bộ giải mã lỗi.
Trong tư vấn bảo mật ngày 21/10, Node.js mô tả một chuyển khối không hợp lệ bị hiểu nhầm là bộ giải mã chỉ cần thêm dữ liệu, thay vì lỗi định dạng không thể phục hồi. Bộ giải mã dạng streaming vì vậy tiếp tục nối byte vào bộ đệm nội bộ chỉ có 8 byte, dẫn đến ghi ra ngoài giới hạn. Tùy tình huống, lỗi có thể làm tiến trình sập, làm lộ dữ liệu trong bộ nhớ hoặc mở đường tới thực thi mã từ xa; đây không phải kết luận rằng mọi hệ thống bị ảnh hưởng đều có thể bị chiếm quyền từ xa.
Điều kiện khai thác thực tế là ứng dụng phải giải nén dữ liệu Brotli do đối thủ kiểm soát. Kịch bản có thể là máy chủ nhận nội dung nén từ request, nhưng cũng có thể là dịch vụ chủ động tải một phản hồi HTTP đã bị tạo độc hại rồi giải nén. Vì thế, chỉ lọc request đầu vào tại proxy không che được đường đi thứ hai.
Phạm vi phụ thuộc vào decoder mà ứng dụng thực sự nạp
Node.js xác nhận các nhánh 22.x, 24.x và 26.x bị ảnh hưởng, với các bản vá lần lượt là 22.23.4, 24.22.1 và 26.12.1. Các gói Brotli độc lập được nêu trong thông tin ứng phó gồm 1.0.3–1.0.9, 1.1.0 và 1.2.0; phiên bản sửa lỗi là 1.0.10, 1.1.1 và 1.2.1. Bản Python Brotli 1.2.1 và brotlicffi 1.2.1.0 cũng có bản vá.
Danh sách này không có nghĩa mọi ứng dụng viết bằng Node.js hay Python đều đang dễ bị khai thác. Cần xác định thành phần giải nén nào được đóng gói hoặc nạp trong từng dịch vụ. Nếu runtime tự mang theo bản decoder riêng, thư viện của hệ điều hành có thể đã được cập nhật nhưng tiến trình vẫn dùng mã cũ. Ngược lại, ứng dụng có thể gọi thư viện Brotli bên ngoài và cần vá đúng gói đó.
Microsoft cũng phát hành cập nhật khẩn cấp cho .NET; thông tin công bố cảnh báo khả năng nâng quyền trên hệ thống có phiên bản bị ảnh hưởng. Các ứng dụng và công cụ khác có tích hợp decoder Brotli cũng cần được rà theo dependency thực tế, thay vì suy từ tên framework hoặc chỉ nhìn danh sách gói hệ điều hành.
Vá đúng runtime quan trọng hơn một lần cập nhật hệ điều hành
Với Node.js, ưu tiên nâng lên bản đã vá trong nhánh đang vận hành, sau đó khởi động lại toàn bộ tiến trình để mã mới được nạp. Nếu ứng dụng chạy trong container, cần dựng lại image từ dependency/runtime đã cập nhật rồi triển khai image mới; chỉ nâng gói trên máy chủ không thay đổi được lớp thư viện đã đóng gói sẵn trong image cũ.
Doanh nghiệp nên kiểm tra lockfile, danh sách dependency và cấu hình build để tìm các gói như Brotli hoặc wrapper HTTP có bật hỗ trợ giải nén. Với Python, thông tin ứng phó khuyến nghị cập nhật các gói Brotli liên quan; nếu chưa thể vá ngay, có thể tạm gỡ thành phần dễ tổn thương hoặc tùy chọn Brotli không thiết yếu, đồng thời hạn chế request nén đến ở lớp proxy. Đây là biện pháp giảm rủi ro, không thay cho bản vá.
WAF hay proxy chỉ chặn được một phần luồng nếu ứng dụng còn tải nội dung từ dịch vụ khác. Một microservice nhận phản hồi Brotli từ bên ngoài vẫn có thể giải nén dữ liệu nguy hiểm, dù cổng nhận request của chính nó đã được lọc. Kiểm kê cần bao gồm cả phần mềm hướng ra Internet lẫn dịch vụ nhận kết nối, cùng việc xác minh phiên bản decoder mà mỗi tiến trình thực sự sử dụng.
Điều cần theo dõi là độ phủ của các bản vá trong chuỗi triển khai
Với đội kỹ thuật tại Việt Nam, việc cần làm không phải chỉ kiểm tra máy chủ đã cập nhật hay chưa, mà là xác nhận bản vá đã đi tới runtime, dependency, image và tiến trình đang phục vụ người dùng. Sau cập nhật, cần xác nhận phiên bản chạy thực tế và hoàn tất khởi động lại hoặc triển khai lại; nếu không, trạng thái trên máy build có thể khác với dịch vụ đang hoạt động.
Các báo cáo công khai ghi nhận đã có mã khai thác thử nghiệm, nhưng chưa có báo cáo xác nhận khai thác độc hại ngoài thực tế ở thời điểm bài được cập nhật. Mức độ nghiêm trọng vẫn đáng để xử lý sớm vì đường vào không chỉ là request gửi trực tiếp tới máy chủ: bất kỳ ứng dụng nào giải nén dữ liệu Brotli không đáng tin đều cần được xem xét. Bản vá cụ thể và decoder đang dùng mới quyết định hệ thống đã được bảo vệ hay chưa.
Nguồn tham khảo: Node.js Project, BleepingComputer, TechRadar.
