CVE-2026-111497: Một lỗi Brotli, chín runtime và Codex Agent đã phát hiện ra nó

Điều trớ trêu về CVE-2026-111497 là nó không phải một lỗ hổng trong một sản phẩm. Nó là một lỗi ghi ngoài phạm vi trong bộ giải nén Brotli của Google, và cùng lỗi đó có thể tiếp cận được thông qua ít nhất tám runtime và proxy riêng biệt có nhúng thư viện này — Node.js, .NET và ASP.NET Core, Brotli và brotlicffi của Python, Bun, Envoy, Istio, và bản triển khai thuần Go. Phép đo của Wiz đặt 91% môi trường đám mây vào diện rủi ro và lưu ý rằng 82% trong số đó để lộ Node.js ra công khai. CISA đã thêm nó vào danh mục Các lỗ hổng đã bị khai thác được biết đến, và Microsoft đã phát hành bản vá khẩn cấp cho .NET và Visual Studio.

Nửa sau của câu chuyện là ai đã tìm ra nó: Khai Tran và Sylvie Mayer thuộc OpenAI Codex Security, theo bài viết của Wiz và các ghi công từ thượng nguồn. Đó là một đội tác nhân bảo mật AI, và lỗ hổng mà nó tìm thấy nằm trong thư viện giải nén được nhúng rộng rãi nhất trên web.

Lỗi này gây ra những gì

Brotli là thứ mà gần như mọi stack HTTP đều giải nén khi máy chủ gửi code>Content-Encoding: br/code>. Một luồng nén bị hỏng gây ra ghi ngoài biên trong quá trình giải nén, và điểm CVSS v4 là 9.2. Phạm vi bị ảnh hưởng là Brotli 1.0.3 đến 1.2.0, được sửa trong 1.0.10, 1.1.1 và 1.2.1.

Điều khiến nó trở thành một chương trình thay vì một ticket là việc thư viện được nhúng kèm, liên kết tĩnh hoặc triển khai lại trong từng runtime, nên bản sửa lỗi đến qua một nhịp phát hành khác nhau trong mỗi trường hợp — và đôi khi hoàn toàn không đến, vì bản phân phối chuẩn của một ngôn ngữ có bản sao riêng của nó.

Danh sách bản vá, phần hữu ích.

Mọi số liệu dưới đây đều lấy từ bản tóm tắt tư vấn của Wiz và các bản phát hành dự án tương ứng, được ghi nhận vào ngày 30 tháng 10 năm 2026.

• Google Brotli / libbrotli — bị ảnh hưởng ở các phiên bản 1.0.3–1.2.0, không bao gồm các bản backport đã được vá; đã được sửa trong 1.0.10, 1.1.1, 1.2.1.

• Python Brotli — bị ảnh hưởng ở các phiên bản 1.0.3–1.2.0; đã khắc phục trong 1.2.1. brotlicffi — bị ảnh hưởng ở các phiên bản 1.0.3–1.2.0.x; đã khắc phục trong 1.2.1.0.

• Node.js — ảnh hưởng đến 22.x, 24.x và 26.x; đã sửa trong 22.23.4, 24.22.1 và 26.12.1.

• Bun — bị ảnh hưởng 1.0.21–1.4.3; đã khắc phục trong 1.4.4.

• Envoy Proxy — các phiên bản bị ảnh hưởng: 1.36.11, 1.37.7, 1.38.5, 1.39.2; đã khắc phục trong 1.36.12, 1.37.8, 1.38.6, 1.39.3 và 1.40.0.

• Istio — bị ảnh hưởng ở các phiên bản 1.29.0–1.29.8, 1.30.0–1.30.5, 1.31.0–1.31.1; đã được sửa trong 1.29.9, 1.30.6 và 1.31.2.

• andybalholm/brotli (Go) — bị ảnh hưởng trước v1.2.7; đã khắc phục trong v1.2.7.

Hàng Node.js là hàng quyết định tuần làm việc của phần lớn mọi người. Một dịch vụ chạy trên 22.22.x bị lộ qua stack HTTP của nó ngay cả khi mã ứng dụng không hề nhắc đến Brotli, vì việc giải nén diễn ra trước khi handler của bạn được gọi. Điều đó cũng giải thích ba cái tên mà ngành gắn cho nó: Node2Shell cho đường Node, HTTP2Shell cho đường proxy mà Check Point đã ghi nhận, và Brotli2Shell từ JFrog cho bức tranh rộng hơn.

Tại sao “91%” là con số đáng để tranh luận

Các con số của Wiz mô tả tài sản đám mây của khách hàng Wiz, chứ không phải toàn bộ internet. Việc đếm số môi trường có một thư viện dễ bị tổn thương ở đâu đó bên trong không phải là đếm số dịch vụ có thể bị khai thác, và khác biệt này là rất lớn: một Brotli được đóng gói bên trong một ứng dụng desktop mà không bao giờ giải nén dữ liệu đầu vào không đáng tin cậy là một phát hiện, chứ không phải một lỗ hổng. Phiên bản hữu ích của số liệu thống kê này hẹp hơn — những dịch vụ chấp nhận dữ liệu đầu vào đã nén từ các nguồn không đáng tin cậy, mà về cơ bản là mọi endpoint HTTP công khai kết thúc bằng code>br/code>.

Hai điều khiến việc khai thác trở nên khả dĩ chứ không chỉ là lý thuyết: việc CISA bổ sung vào danh mục KEV ngụ ý đã quan sát thấy khai thác, và các nhà vận hành honeypot đã ghi nhận các nỗ lực. Khi một lỗ hổng bước vào cột "bị khai thác ngoài thực tế", thời hạn vá không còn là lịch kiểm soát thay đổi của bạn nữa mà trở thành của người khác.

Phát hiện là phần có chu kỳ bán rã dài hơn.

Đội bảo mật của một mô hình tiên phong đã tìm ra một lỗi an toàn bộ nhớ trong một thư viện giải nén mà hàng nghìn người đã đọc trong hơn một thập kỷ. Đó không phải là câu chuyện về một nhà cung cấp nào đó thông minh; đó là một tuyên bố về độ phủ. Phân tích tĩnh đã được áp dụng cho Brotli trong nhiều năm, các harness fuzzing đã tồn tại, và lỗi này vẫn tồn tại qua cả hai — trong khi một tác nhân được thiết kế để đọc mã một cách có mục đích đã tìm thấy nó và tạo ra một bản vá mà upstream đã chấp nhận.

Sự bất đối xứng ấy cắt theo cả hai chiều. Chính năng lực tìm ra loại lỗi này cũng sẽ tìm thấy nó trong đoạn mã bạn phát hành. Câu hỏi đối với bất kỳ ai vận hành việc lập trình bằng tác nhân AI không phải là liệu tác nhân có phát hiện được lỗi ghi ngoài phạm vi hay không; mà là liệu phát hiện đó có đến với bạn trước khi nó đến với người khác hay không.

Những việc cần làm, theo thứ tự quan trọng

• Vá các runtime mà bạn thực sự vận hành. Danh sách thư viện ở trên là nguồn; hãy bắt đầu với những runtime xử lý lưu lượng truy cập công khai.

• Sau đó, hãy tìm các bản sao được nhúng kèm. Ảnh nền container, tệp nhị phân tĩnh, bản dựng WASM và gói wheel ngôn ngữ đều mang Brotli riêng của chúng, và không bản nào trong số đó sẽ xuất hiện trong một cuộc kiểm tra của trình quản lý gói đối với ứng dụng. Một trình quét kiểm kê cấp kho mã nguồn được công bố tuần này sẽ duyệt qua hệ thống tệp và đánh giá mọi bản sao Node, Bun và Brotli mà nó tìm thấy, đây là một khởi đầu nhanh hơn so với việc tự tạo một cái.

• Khi có thể, hãy xây dựng lại thay vì vá. Việc thay thế một thư viện liên kết tĩnh bên trong một sản phẩm đã biên dịch chính là nơi người ta dễ vô tình phát hành một tệp nhị phân chỉ được sửa một phần.

• Nếu bạn chạy Envoy hoặc Istio làm lớp biên, hãy coi các bản sửa lỗi proxy là ưu tiên cao nhất trong nhóm này: proxy giải nén thay mặt cho mọi thứ phía sau nó.

• Kiểm tra riêng hệ thống .NET của bạn. Bản vá của Microsoft bao gồm .NET và Visual Studio, và phiên bản đúng là bản cập nhật runtime chứ không phải thay đổi tham chiếu gói.

Vị trí của vấn đề này đối với độc giả của chúng ta

Phần lớn nội dung blog này đề cập đến năng lực của mô hình, giá cả và định tuyến. Điều này thuộc về đây vì một dòng: lỗi đã được phát hiện bởi một tác nhân AI, và lớp hệ thống phát hiện những lỗi như vậy chính là lớp hệ thống mà độc giả của chúng ta đang nối vào pipeline của họ. Một tác nhân quét kho mã chạy trong CI đối với các phụ thuộc của bạn giờ đây là một biện pháp kiểm soát bảo mật, và nó cũng chính là môi trường chạy tác nhân viết mã của bạn.

Agent Firewall của OrcaRouter đánh giá các lệnh gọi công cụ và MCP trước khi chúng thực thi, đây là biện pháp kiểm soát giúp giới hạn phạm vi tác động của agent; nó không làm cho các phát hiện của agent trở nên đúng, và không có gì trong CVE này là tuyên bố rằng việc định tuyến một mô hình làm giảm rủi ro chuỗi cung ứng. Điều hữu ích cần rút ra từ tuần này hẹp hơn và có thể kiểm chứng: nếu bạn đã cấp cho agent quyền đọc kho lưu trữ để tìm lỗi, hãy xác minh rằng các bản vá được đề xuất của nó được ghim phiên bản, và xác minh rằng runtime bên dưới ngăn xếp của chính bạn đã vượt qua 1.0.3–1.2.0.

Điều đáng ghi nhớ là lỗ hổng nằm trong đoạn mã mà không ai chủ động chọn. Brotli xuất hiện như một phụ thuộc bắc cầu của một tính năng runtime, đã được vá ở tám nơi theo những lịch trình riêng, và sẽ tiếp tục xuất hiện bên trong các image nền được build trước tuần này. Ứng phó chuỗi cung ứng phần lớn là kỷ luật tìm ra những bản sao mà bạn không hề cài đặt.

Ghi chú nguồn: ma trận phiên bản bị ảnh hưởng và đã vá, danh sách runtime và các con số phơi lộ 91%/82% lấy từ bản tóm tắt khuyến nghị của Wiz đọc ngày 30 tháng 10 năm 2026, còn các phiên bản đã vá là các bản phát hành của chính các dự án. Điểm CVSS v4 9,2 lấy từ bản ghi CVE. Việc ghi nhận công lao phát hiện cho Khai Tran và Sylvie Mayer của OpenAI Codex Security lấy từ bài viết của Wiz và các ghi nhận công lao từ upstream. Danh sách KEV của CISA và bản vá .NET của Microsoft là thông báo của các tổ chức tương ứng; ở đây, cả hai đều không được đọc như tài liệu gốc ngoài bản tóm tắt khuyến nghị. Mô tả của inventory-scanner là mô tả của chính một dự án GitHub của bên thứ ba.