Thông tin về CVE-2026-111497 khiến nhiều quản trị viên cân nhắc tắt Brotli trên CDN để giảm rủi ro. Tuy nhiên, lỗ hổng nằm ở bước giải nén dữ liệu Brotli do bên ngoài kiểm soát, nên tắt nén response trên CDN chưa chắc xử lý được điểm yếu trong ứng dụng. Cần xác định thành phần nào đang giải mã Brotli và dữ liệu đến từ đâu trước khi thay đổi cấu hình.
CVE-2026-111497 là gì và điều kiện nào khiến website gặp rủi ro?
CVE-2026-111497 là lỗi ghi vượt phạm vi bộ nhớ trong bộ giải mã Brotli, được kích hoạt khi một ứng dụng giải nén luồng dữ liệu được tạo có chủ đích. Node.js xác nhận các nhánh 22.x, 24.x và 26.x bị ảnh hưởng; vấn đề cũng xuất hiện trong các sản phẩm khác dùng Brotli, nên cần rà soát decoder thay vì chỉ nhìn cài đặt nén của website.
CVE-2026-111497 (còn được gọi là Node2Shell hoặc HTTP2Shell) là một lỗ hổng bảo mật nghiêm trọng
Lỗ hổng nằm ở bước giải nén dữ liệu không đáng tin cậy
Để đường khai thác này được kích hoạt, một thành phần phải nhận và giải mã luồng Brotli do kẻ tấn công kiểm soát. Ví dụ có thể là ứng dụng nhận request body với Content-Encoding: br, API gọi hàm giải nén Brotli, hoặc HTTP client tự giải mã một response Brotli từ nguồn không đáng tin cậy. Node.js nêu rõ dữ liệu lỗi định dạng được đưa vào node:zlib có thể làm hỏng bộ nhớ của tiến trình.
Mức độ ảnh hưởng tùy vào sản phẩm, bản dựng, quyền của tiến trình và khả năng tiếp cận đầu vào. Không nên mặc định mọi trường hợp đều dẫn đến thực thi mã từ xa; nhưng cũng không nên bỏ qua rủi ro crash hoặc lộ bộ nhớ trong khi chờ bản vá. Red Hat lưu ý rằng việc xử lý dữ liệu Brotli không tin cậy là điều kiện quan trọng để chạm tới đường lỗi.
Thành phần cần rà soát không chỉ có Node.js
Ngoài Node.js, các cảnh báo đã nhắc tới một số bản .NET, thư viện Python Brotli/brotlicffi, Java brotli4j, Bun và proxy như Envoy. NCSC New Zealand cho biết họ nhận thấy khai thác thực tế; danh sách ảnh hưởng và bản sửa thay đổi theo phiên bản, hệ điều hành và cách đóng gói, nên cần kiểm tra advisory của đúng nhà cung cấp. Trung tâm An ninh mạng Canada khuyến nghị rà soát cả ứng dụng và phần mềm bên thứ ba có nhúng hoặc phụ thuộc vào Brotli.
Website dùng CDN có cần tắt nén Brotli không?
Thông thường, không nên tắt nén Brotli trên CDN chỉ vì CVE-2026-111497. Cần phân biệt CDN nén nội dung để gửi tới trình duyệt với một thành phần đang giải nén dữ liệu Brotli do người dùng hoặc hệ thống bên ngoài gửi vào. Hai thao tác này đi theo các hướng khác nhau và có thể nằm trên những máy chủ khác nhau.
Không, website dùng CDN không cần tắt nén Brotli, mà ngược lại nên bật cả trên máy chủ gốc lẫn trên CDN
CDN chỉ nén response để gửi nội dung tới người dùng
Trong luồng phổ biến, trình duyệt gửi Accept-Encoding: br để báo rằng có thể nhận nội dung Brotli; CDN hoặc máy chủ gốc tạo response đã nén và trả về với Content-Encoding: br. Việc này là nén đầu ra. Chỉ riêng việc bật tính năng đó không chứng minh ứng dụng gốc đang dùng decoder bị lỗi để xử lý dữ liệu đầu vào không tin cậy.
Để phân biệt vai trò phân phối nội dung của CDN với máy chủ gốc, có thể xem tài liệu về cách Bizfly Cloud CDN hoạt động. Hướng dẫn nén Gzip của Bizfly Cloud cũng minh họa cách trình duyệt và máy chủ trao đổi qua Accept-Encoding và Content-Encoding; đây là kiến thức về luồng header, không thay cho việc kiểm tra decoder Brotli.
Một ví dụ cụ thể là Cloudflare cho biết quy tắc WAF liên quan CVE này nhắm vào request khai báo Content-Encoding: br; quy tắc không khớp với Accept-Encoding: br và không tác động tới cấu hình nén response Brotli của Cloudflare. Hướng dẫn này áp dụng cho cách Cloudflare thiết kế quy tắc; với nhà cung cấp CDN khác, cần xác nhận luồng xử lý và tình trạng bản vá trực tiếp với nhà cung cấp.
CDN hoặc ứng dụng có giải nén request Brotli
Nếu CDN, reverse proxy, API gateway hoặc máy chủ ứng dụng giải mã request body có Content-Encoding: br, dữ liệu từ người dùng có thể đi tới decoder. Khi thành phần giải nén chưa được vá và endpoint cho phép người lạ gửi dữ liệu, đây là đường cần ưu tiên xử lý. Hãy xác định chính xác request nào được phép mang nội dung nén và thành phần nào đọc, giải nén nó.
Tương tự, ứng dụng phía máy chủ có thể tự lấy dữ liệu từ dịch vụ khác bằng fetch() hoặc HTTP client có tính năng giải nén tự động. Khi đó, việc tắt nén response cho người truy cập website không xử lý được dữ liệu Brotli được giải mã trong luồng gọi dịch vụ phía sau.
CDN có thể là một lớp cần hỏi nhà cung cấp
CDN và proxy thường có nhiều chức năng xử lý nội dung, nhưng cấu hình, phiên bản thư viện và cách giải mã khác nhau theo nhà cung cấp. Hãy hỏi rõ liệu sản phẩm có giải mã request Brotli, có nhận nội dung Brotli từ origin để biến đổi hay không, phiên bản thành phần đã được vá chưa và khách hàng có cần thay đổi cấu hình nào không. Không nên suy luận rằng CDN đã an toàn hoặc đang bị ảnh hưởng chỉ từ việc dashboard có công tắc Brotli.
Cách xử lý CVE-2026-111497 cho website đang chạy CDN
Hướng xử lý nên bắt đầu từ việc tìm decoder và nguồn dữ liệu đi vào nó. Sau đó cập nhật đúng thành phần, triển khai lại toàn bộ môi trường cần thiết và chỉ dùng biện pháp tạm thời có phạm vi rõ ràng khi chưa thể vá.
Kiểm kê runtime, thư viện và đường giải nén
Rà soát phiên bản Node.js, .NET, Python và Java; các gói Brotli trong lockfile/SBOM; image container; thư viện hệ điều hành; reverse proxy, gateway và HTTP client. Tìm cả đường giải nén trực tiếp như BrotliDecompress hoặc zlib lẫn giải nén tự động qua thư viện mạng.
Tập trung vào endpoint nhận upload hoặc request body nén, dịch vụ đọc dữ liệu do người dùng cung cấp, tác vụ nền xử lý file và các tiến trình gọi nguồn bên ngoài. Kiểm tra log hoặc cấu hình để phân biệt Accept-Encoding ở request gửi đi với Content-Encoding của payload thực tế; hai header này không thể thay thế nhau khi xác định hướng dữ liệu.
Cập nhật bản vá và dựng lại môi trường
Với Node.js, các bản vá được phát hành từ Node.js 22.23.4, 24.22.1 và 26.12.1. Do bản 24.22.1 có hồi quy đã được xử lý trong bản 24.22.2, nên với nhánh 24.x hãy dùng 24.22.2 hoặc bản mới hơn. Nếu dùng Brotli độc lập, các bản sửa upstream được nêu là 1.0.10, 1.1.1 và 1.2.1 tương ứng với các nhánh phiên bản; bản phân phối Linux có thể backport bản sửa mà không đổi số phiên bản upstream. Hãy theo hướng dẫn của nhà cung cấp cho đúng nền tảng thay vì chỉ so sánh chuỗi phiên bản.
Sau khi nâng cấp, dựng lại container hoặc gói triển khai để bản vá thực sự có trong image đang chạy. Với môi trường được quản lý, xác minh trạng thái cập nhật theo hướng dẫn dịch vụ; một bản runtime mới trong kho không có nghĩa mọi function hoặc máy ảo đã nhận bản đó. AWS cũng lưu ý phạm vi Brotli rộng hơn Node.js và việc cập nhật runtime managed có thể cần thao tác triển khai hoặc xác minh riêng.
Giảm tiếp xúc tạm thời nếu chưa thể vá
Trong lúc chờ bản sửa, biện pháp sát với điều kiện khai thác là ngăn thành phần bị ảnh hưởng giải nén Brotli từ nguồn không tin cậy. Có thể tạm từ chối request body Content-Encoding: br ở endpoint không cần chức năng này, hoặc tắt riêng chức năng giải nén tự động trong thư viện liên quan nếu nhà cung cấp hỗ trợ. Trung tâm An ninh mạng Canada cũng khuyến nghị không để ứng dụng bị ảnh hưởng xử lý nội dung Brotli từ nguồn không đáng tin cậy cho đến khi cập nhật được.
Website dùng CDN không bắt buộc phải tắt nén Brotli trừ khi hệ thống đang sử dụng trực tiếp dính lỗi
Nếu dùng WAF để chặn, nên chạy chế độ ghi log hoặc quan sát trước, kiểm tra request bị khớp rồi mới chuyển sang chặn. Quy tắc chặn có thể làm lỗi các tích hợp hợp lệ gửi body nén. WAF chỉ kiểm tra được loại lưu lượng nằm trong phạm vi của nó; ví dụ AWS nêu biện pháp WAF ở tầng request không xử lý dữ liệu Brotli đến từ response của dịch vụ upstream. Vì thế, WAF là biện pháp giảm tiếp xúc tạm thời, không thay thế bản vá decoder.
Có thể tham khảo tài liệu Bizfly Cloud về cách WAF phân tích request HTTP/HTTPS để hiểu cơ chế kiểm tra lưu lượng ở tầng ứng dụng. Nội dung này không xác nhận có sẵn rule chuyên biệt cho CVE-2026-111497; hãy hỏi nhà cung cấp về rule, phạm vi kiểm tra và cách xử lý request Brotli trước khi dựa vào WAF như một biện pháp giảm thiểu.
Xác minh sau cập nhật và theo dõi bất thường
Sau khi triển khai, xác nhận phiên bản runtime và thư viện thực tế trong từng container, function hoặc máy chủ; kiểm tra lại image tag/digest và quy trình tự động triển khai. Theo dõi lỗi giải nén, tiến trình bị dừng bất thường, request nén bất thường và dấu hiệu truy cập trái phép. Nếu hệ thống từng xử lý dữ liệu Brotli không tin cậy khi còn phiên bản bị ảnh hưởng, cần đánh giá nhật ký và phạm vi quyền của tiến trình, không chỉ cài bản vá rồi đóng sự cố.
Bảng quyết định nhanh: khi nào cần tắt Brotli?
| Tình huống | Hành động phù hợp |
|---|---|
| CDN chỉ nén response website để gửi cho trình duyệt | Chưa cần tắt chỉ vì CVE này; kiểm tra advisory của nhà cung cấp và vá decoder trong ứng dụng nếu có. |
API hoặc máy chủ giải nén request Content-Encoding: br từ người dùng | Vá decoder ngay; tạm chặn riêng request Brotli nếu chưa thể cập nhật và kiểm tra ảnh hưởng chức năng. |
| Backend tự giải nén response Brotli từ dịch vụ bên ngoài | Cập nhật HTTP client/runtime/thư viện và đánh giá nguồn dữ liệu; tắt nén CDN website không xử lý đường này. |
| Chưa rõ CDN có giải nén hay dùng thư viện Brotli nào | Hỏi nhà cung cấp về thành phần, bản vá, luồng request/response; không suy đoán từ công tắc bật/tắt. |
Với doanh nghiệp đang dùng Dịch vụ CDN, hãy xem cấu hình phân phối và tối ưu nội dung của dịch vụ, đồng thời xác minh riêng với đội ngũ kỹ thuật về thành phần xử lý Brotli tại CDN. Dù dùng nhà cung cấp nào, cần kiểm tra cả CDN lẫn máy chủ gốc: CDN phân phối nội dung không tự động cập nhật runtime hoặc thư viện của ứng dụng.
Câu hỏi thường gặp về lỗ hổng Brotli
Các câu trả lời dưới đây giúp phân biệt việc website phát Brotli cho người dùng với việc máy chủ giải nén dữ liệu bên ngoài. Khi kiểm tra, hãy xác định đúng thành phần và hướng đi của dữ liệu trước khi đổi cấu hình CDN.
Tắt Brotli trên CDN có khắc phục CVE-2026-111497 không?
Không phải trong mọi trường hợp. Tắt nén response chỉ thay đổi cách nội dung được gửi tới trình duyệt; nếu Node.js hoặc ứng dụng phía máy chủ vẫn giải nén dữ liệu Brotli không tin cậy, decoder đó vẫn cần được vá hoặc tạm ngừng xử lý loại đầu vào này.
Website WordPress có bị ảnh hưởng không?
Không thể kết luận chỉ từ việc website chạy WordPress. Cần kiểm tra các dịch vụ phụ trợ như Node.js cho SSR hoặc build, proxy, API gateway, plugin/dịch vụ ngoài và thư viện nào đang giải nén Brotli. Nếu không có thành phần dễ bị ảnh hưởng thì đường tấn công nêu trên có thể không hiện diện, nhưng vẫn nên rà soát hạ tầng liên quan.
Đổi từ Brotli sang gzip có đủ an toàn không?
Không. Chuyển sang gzip có thể đổi định dạng nội dung được nén trong một luồng cụ thể, nhưng không cập nhật thư viện Brotli dễ bị lỗi ở nơi khác trong ứng dụng. Chỉ dùng biện pháp này như thay đổi tạm thời có mục tiêu sau khi xác định luồng dữ liệu; vẫn phải cập nhật decoder bị ảnh hưởng.
Làm sao biết website có nhận request Brotli?
Kiểm tra log request và cấu hình reverse proxy/API gateway để tìm Content-Encoding: br, sau đó xác định dịch vụ nào giải nén body. Đừng nhầm với Accept-Encoding: br, vốn thường chỉ cho biết client chấp nhận nhận response Brotli. Đồng thời kiểm tra HTTP client phía server vì nó có thể tự giải nén response từ một dịch vụ khác mà không có request upload từ người dùng.
Kết luận
CVE-2026-111497 không đồng nghĩa website dùng CDN phải tắt Brotli trên diện rộng. Hãy tìm thành phần đang giải nén dữ liệu Brotli không tin cậy, cập nhật decoder và dựng lại môi trường; nếu chưa thể vá, tạm hạn chế đúng đường nhận dữ liệu nén. Chỉ tắt nén response trên CDN khi nhà cung cấp xác nhận thay đổi đó cần thiết cho chính luồng xử lý đang bị ảnh hưởng.
