Lỗ hổng Brotli Decoder: Khi một gói nén nhỏ đe dọa hàng triệu máy chủ

Bạn có bao giờ nghĩ rằng một thuật toán nén dữ liệu – thứ tưởng chừng vô hại và chỉ làm cho trang web tải nhanh hơn – lại có thể trở thành cánh cửa để kẻ tấn công chiếm đoạt toàn bộ máy chủ của bạn? Nghe có vẻ khó tin, nhưng đó chính xác là những gì đang diễn ra với lỗ hổng Brotli decoder mang mã CVE-2026-111497.

Trong nhiều năm, Brotli được xem là một trong những thành tựu thầm lặng của Google – một thuật toán nén dữ liệu hiệu quả, giúp giảm kích thước trang web và cải thiện tốc độ tải. Nó có mặt ở khắp mọi nơi, từ các trang web bạn truy cập hàng ngày, đến các ứng dụng bạn dùng trên điện thoại, đến những hệ thống máy chủ vận hành nền tảng số của cả một doanh nghiệp. Nhưng chính sự phổ biến đó lại biến một lỗi nhỏ trong mã nguồn thành một mối đe dọa quy mô toàn cầu.

Hãy cùng tôi, SilverZ, mổ xẻ lỗ hổng này từ gốc rễ. Bởi vì nếu bạn đang vận hành bất kỳ dịch vụ nào có xử lý dữ liệu nén Brotli – và rất có thể là bạn đang làm vậy – thì đây không phải là tin tức bạn có thể bỏ qua.

Lỗ hổng Brotli decoder là gì và tại sao nó nguy hiểm?

CVE-2026-111497 là một lỗ hổng ghi ngoài phạm vi bộ đệm (out-of-bounds write) trong bộ giải mã Brotli. Nói một cách đơn giản, khi chương trình giải nén một luồng dữ liệu Brotli bị lỗi hoặc được tạo ác ý, nó có thể ghi dữ liệu vượt quá vùng bộ nhớ được cấp phát, phá hỏng cấu trúc bộ nhớ và mở đường cho kẻ tấn công thực thi mã từ xa (Remote Code Execution – RCE).

Hãy hình dung thế này: bộ giải mã Brotli giống như một người thư ký nhận một chồng tài liệu đã được nén lại và có nhiệm vụ giải nén chúng ra. Nếu chồng tài liệu đó được sắp xếp đúng cách, mọi thứ diễn ra suôn sẻ. Nhưng nếu ai đó cố tình gửi một chồng tài liệu được sắp xếp sai lệch, người thư ký có thể đọc nhầm và ghi thông tin ra ngoài phạm vi cho phép – tạo ra một lỗ hổng để kẻ tấn công chèn mã độc vào hệ thống.

Điều khiến lỗ hổng này trở nên đặc biệt nguy hiểm là nó nằm trong mã C của bộ giải mã Brotli, thứ được nhúng vào rất nhiều chương trình khác nhau. Từ Node.js – môi trường chạy JavaScript phổ biến nhất cho backend – đến Bun, một runtime mới nổi đang được ưa chuộng. Từ các gói Python Brotli và brotlicffi đến Envoy proxy – thành phần quan trọng trong các kiến trúc microservices hiện đại.

Phạm vi ảnh hưởng: Không chỉ Node.js

Mặc dù tên gọi thường gắn với Node.js, lỗ hổng này thực chất ảnh hưởng đến toàn bộ hệ sinh thái phần mềm sử dụng Brotli decoder. Và danh sách đó rất dài.

Node.js là cái tên được nhắc đến nhiều nhất, với các phiên bản bị ảnh hưởng bao gồm 22.x, 24.x và 26.x. Bất kỳ dịch vụ Node.js nào giải nén dữ liệu Brotli từ nguồn không đáng tin cậy đều có nguy cơ bị tấn công. Điều này bao gồm các ứng dụng sử dụng fetch() để nhận phản hồi với header Content-Encoding: br, hoặc các ứng dụng dùng Express 5 và body-parser 2 để xử lý request body được nén bằng Brotli.

Bun – runtime JavaScript mới đang thu hút sự chú ý – cũng bị ảnh hưởng trong các phiên bản 1.2.x và 1.3.x. Tương tự Node.js, Bun có thể giải nén Brotli khi nhận phản hồi từ fetch hoặc khi xử lý request body.

Trong thế giới Python, lỗ hổng len lỏi vào các gói Brotli và brotlicffi. Điều đáng sợ là ngay cả khi ứng dụng của bạn không trực tiếp import Brotli, chỉ cần một trong hai gói này được cài đặt, các HTTP client như requests, urllib3, httpx và aiohttp có thể tự động giải nén phản hồi Brotli – và bạn trở thành mục tiêu mà không hề hay biết.

Envoy và Istio – những proxy phổ biến trong kiến trúc microservices – chỉ bị ảnh hưởng khi tính năng giải nén Brotli được bật. Nhưng nếu bạn đang sử dụng tính năng đó, đây là lúc phải hành động.

Mức độ nghiêm trọng: Những con số biết nói

Không phải tất cả các tổ chức đều đánh giá lỗ hổng này giống nhau, và sự khác biệt trong cách chấm điểm cũng đáng để lưu tâm.

Google – đơn vị đã cấp CVE – chấm lỗ hổng này 9.2 trên thang CVSS 4.0, mức nghiêm trọng (critical). Đây là mức cao nhất trong các đánh giá, phản ánh mức độ nguy hiểm tiềm tàng của lỗ hổng.

Node.js xếp nó vào mức cao (high), trong khi Red Hat đánh giá 8.1 – quan trọng (important). Sự khác biệt này không làm giảm đi mức độ nghiêm trọng của vấn đề. Nó chỉ cho thấy rằng các tổ chức khác nhau có cách nhìn nhận khác nhau về rủi ro, dựa trên môi trường và mức độ phơi nhiễm cụ thể.

Điều đáng chú ý là chưa có báo cáo nào về việc khai thác trong thực tế. CISA ghi nhận mức độ khai thác là "không" và tự động hóa là "không". Red Hat cho biết chưa có bằng chứng khái niệm (proof-of-concept) đáng tin cậy nào được công bố. Nhưng đừng để điều đó khiến bạn chủ quan. Lỗ hổng đã được công khai, mã nguồn đã được vá, và kẻ tấn công đang ngày càng tinh vi hơn. Việc chưa có khai thác không có nghĩa là sẽ không bao giờ có.

Cơ chế tấn công: Khi dữ liệu nén trở thành vũ khí

Để hiểu rõ hơn về mức độ nguy hiểm, hãy cùng phân tích cách lỗ hổng này có thể bị khai thác.

Kịch bản thứ nhất: máy chủ bị tấn công bởi client độc hại. Một kẻ tấn công gửi request đến máy chủ của bạn với body được nén bằng Brotli – nhưng dữ liệu nén đó đã được tạo ác ý để kích hoạt lỗi ghi ngoài phạm vi bộ đệm. Nếu máy chủ của bạn giải nén request body đó (ví dụ qua Express hoặc body-parser), lỗ hổng có thể bị kích hoạt và kẻ tấn công có thể chạy mã trên máy chủ của bạn.

Kịch bản thứ hai: client bị tấn công bởi máy chủ độc hại. Ứng dụng của bạn gửi request đến một máy chủ khác và nhận về phản hồi được nén bằng Brotli. Nếu máy chủ đó là độc hại và gửi dữ liệu được tạo ác ý, quá trình giải nén có thể bị lỗi và dẫn đến thực thi mã trên máy của bạn. Ngay cả một lệnh đơn giản như curl --compressed cũng có thể trở thành vector tấn công nếu máy chủ trả về dữ liệu độc hại.

Điều này có nghĩa là cả hai phía của kết nối đều có thể là mục tiêu. Bạn không chỉ cần bảo vệ máy chủ của mình khỏi những request độc hại, mà còn cần bảo vệ các client của mình khỏi những phản hồi độc hại từ bên ngoài.

Tại sao việc cập nhật dependency không giải quyết được vấn đề?

Đây là một điểm cực kỳ quan trọng mà nhiều đội ngũ phát triển có thể bỏ qua. Lỗ hổng này nằm trong mã nguồn của runtime – Node.js, Bun, Python – chứ không phải trong các gói thư viện mà bạn cài đặt qua npm, pip hay bất kỳ trình quản lý gói nào.

Điều đó có nghĩa là các công cụ quét dependency như Dependabot, Snyk hay npm audit có thể không phát hiện ra lỗ hổng này. Chúng kiểm tra các gói thư viện, không kiểm tra runtime. Và ngay cả khi bạn cập nhật tất cả các gói thư viện lên phiên bản mới nhất, runtime vẫn có thể đang chứa bộ giải mã Brotli lỗi thời.

Với Python, tình hình còn phức tạp hơn. Hồ sơ CVE ghi tên kho lưu trữ Brotli của Google, không phải các gói PyPI. Điều này có nghĩa là các công cụ quét dependency có thể không gắn cờ các gói Python là bị ảnh hưởng. Bạn cần kiểm tra thủ công phiên bản đã cài đặt của Brotli và brotlicffi để đảm bảo chúng đã được vá.

Lịch sử kỳ lạ của bản vá: Khi lỗi được sửa nhưng không ai biết

Câu chuyện về bản vá của lỗ hổng này có một chi tiết đáng chú ý. Thay đổi mã nguồn để khắc phục lỗi đã được thêm vào Brotli từ ngày 27 tháng 2. Nhưng vào thời điểm đó, không ai biết rằng thay đổi đó thực sự giải quyết một lỗ hổng bảo mật. Và không có bản phát hành Brotli mới nào chứa bản vá đó cho đến ngày 21 tháng 10.

Điều này có nghĩa là trong gần tám tháng, mã nguồn đã được sửa nhưng người dùng vẫn chưa được bảo vệ. Các chương trình như Node.js, Bun, Python và Envoy – những phần mềm nhúng bộ giải mã Brotli – chỉ có thể cập nhật khi có bản phát hành mới từ dự án Brotli. Và bản phát hành đó đã không đến trong một thời gian dài.

Đây là một bài học quan trọng về quản lý chuỗi cung ứng phần mềm. Ngay cả khi một lỗi được phát hiện và sửa trong mã nguồn, nó vẫn có thể tồn tại trong các sản phẩm mà bạn đang sử dụng nếu bản vá không được phát hành và phân phối kịp thời.

Bạn cần làm gì ngay lúc này?

Nếu bạn đang vận hành bất kỳ hệ thống nào có sử dụng Brotli – và rất có thể là bạn đang làm vậy – đây là những bước cần thực hiện ngay từ hôm nay.

1. Cập nhật runtime lên phiên bản đã vá

Đây là biện pháp quan trọng nhất và không có cách nào thay thế. Với Node.js, hãy nâng cấp lên phiên bản mới nhất trong dòng 22.x, 24.x hoặc 26.x. Với Bun, cập nhật lên phiên bản đã được vá. Với Python, cập nhật gói Brotli và brotlicffi lên phiên bản mới nhất.

2. Khởi động lại dịch vụ và xây dựng lại container

Chỉ cập nhật thôi là chưa đủ. Một tiến trình đang chạy vẫn giữ bộ giải mã cũ trong bộ nhớ cho đến khi nó được khởi động lại. Hãy khởi động lại dịch vụ và xây dựng lại bất kỳ container image nào để đảm bảo bản vá được áp dụng.

3. Từ chối request có Content-Encoding: br trước khi giải nén

Nếu bạn chưa thể cập nhật ngay, hãy cấu hình proxy hoặc parser để từ chối các request có header Content-Encoding: br trước khi chúng được giải nén. Điều này ngăn chặn vector tấn công phổ biến nhất.

4. Tắt giải nén Brotli tự động trong HTTP client

Đối với các client gửi request ra bên ngoài, hãy tắt tính năng tự động giải nén Brotli và từ chối các phản hồi Brotli trước khi chúng được xử lý. Đừng để ứng dụng của bạn trở thành nạn nhân của một máy chủ độc hại.

5. Gỡ cài đặt Brotli trong Python nếu không thực sự cần thiết

Nếu ứng dụng Python của bạn không cần xử lý dữ liệu Brotli, hãy gỡ cài đặt các gói Brotli và brotlicffi. Các HTTP client sẽ tự động chuyển sang gzip và deflate, giảm thiểu rủi ro mà không ảnh hưởng đến chức năng.

6. Kiểm tra thủ công phiên bản đã cài đặt

Đừng chỉ dựa vào các công cụ quét dependency. Hãy kiểm tra thủ công phiên bản Brotli trong môi trường của bạn, đặc biệt là với các gói Python, để đảm bảo chúng đã được vá.

Khi sự phổ biến trở thành gánh nặng

Tôi đã chứng kiến ngành an ninh mạng trải qua không ít cuộc cách mạng trong hai thập kỷ qua. Từ những lỗ hổng đơn giản trong các ứng dụng web, đến những cuộc tấn công chuỗi cung ứng có khả năng ảnh hưởng đến hàng triệu hệ thống cùng lúc. Mỗi lần như vậy, chúng ta lại được nhắc nhở rằng sự phổ biến của một công nghệ tỷ lệ thuận với quy mô rủi ro mà nó mang lại.

Brotli là một ví dụ hoàn hảo. Nó được tạo ra để làm cho web nhanh hơn, hiệu quả hơn. Nó thành công đến mức có mặt ở khắp mọi nơi. Nhưng chính sự thành công đó lại biến một lỗi nhỏ trong mã nguồn thành một mối đe dọa toàn cầu. Và như chúng ta đã thấy, việc sửa lỗi không chỉ đơn giản là cập nhật một gói thư viện. Nó đòi hỏi sự phối hợp giữa các dự án mã nguồn mở, các nhà cung cấp runtime, và những người vận hành hệ thống.

Lỗ hổng Brotli decoder không chỉ là một CVE. Đó là một lời nhắc nhở rằng trong thế giới phần mềm hiện đại, không có hệ thống nào là cô lập. Mọi thành phần, dù nhỏ đến đâu, đều có thể trở thành điểm yếu nếu không được quan tâm đúng mức. Và trách nhiệm bảo vệ không chỉ thuộc về những người viết mã nguồn, mà còn thuộc về tất cả những ai vận hành và sử dụng công nghệ.

Khi một thuật toán nén dữ liệu tưởng chừng vô hại lại có thể trở thành cánh cửa cho kẻ tấn công chiếm đoạt toàn bộ hệ thống, bạn có còn tin rằng việc cập nhật dependency là đủ để bảo vệ mình? Và nếu bạn phát hiện ra rằng runtime mà mình đang sử dụng – thứ nằm sâu bên dưới mọi lớp ứng dụng – vẫn đang chứa một lỗ hổng chưa được vá, bạn sẽ ưu tiên xử lý như thế nào trong khi vẫn phải duy trì hoạt động kinh doanh?