Tencent BrowserSkill chỉ kiểm tra xem ID tiện ích có trông giống thật hay không — bất kỳ tiện ích nào cũng có thể cung cấp cho Agent những trang giả mạo

Vào ngày 17 tháng 9 năm 2026, một người dùng GitHub đăng với tên carfeii đã mở issue #273 đối với dự án mã nguồn mở của Tencent BrowserSkill với một tuyên bố hẹp: daemon cục bộ kết nối tiện ích trình duyệt với tác nhân AI không kiểm tra tiện ích nào đã kết nối, mà chỉ kiểm tra rằng kết nối trông giống một tiện ích. Ba ngày sau, vào ngày 20 tháng 9, VulnCheck đã công bố phát hiện này dưới tên CVE-2026-94111, mô tả một daemon "chấp nhận bất kỳ origin chrome-extension nào có 32 ký tự trong phạm vi a-p", phân loại nó là CWE-346 (lỗi xác thực origin), và ghi công George Chen. Bản khuyến cáo cho nó điểm CVSS 4.0 6.9, mức trung bình, với tác động đến tính toàn vẹn được đánh giá cao, còn tính bảo mật và tính khả dụng ở mức thấp. Không có gì trong hồ sơ cho thấy lỗ hổng đã được sử dụng: kho lưu trữ ghi nhận không có khai thác và xếp hạng độ tin cậy của mục là A, với real_harm là false. Đây là một bản ghi trong kho lưu trữ sự cố AI, nơi mỗi mục mang nguồn, mức độ nghiêm trọng, xếp hạng độ tin cậy và cờ tranh chấp riêng.

Một bước kiểm tra định dạng chưa từng kiểm tra danh tính

Đoạn mã ở trung tâm của bản ghi thì nhỏ. Trong crates/bsk-cli/src/daemon/ws.rs, hàm origin_allowed() nhận header Origin của quá trình bắt tay WebSocket, cắt bỏ chuỗi chrome-extension://, và trả về true nếu phần còn lại dài đúng 32 ký tự và mọi ký tự đều nằm giữa a và p. Đó là toàn bộ phép kiểm tra. Nó được chạy một lần, bên trong callback nâng cấp HTTP, và khi thất bại thì trả về 403 với thông báo "Origin not in chrome-extension allow-list" — mặc dù như đã công bố thì chẳng có danh sách nào để mà nằm trong đó.

Mẫu này không phải ngẫu nhiên. ID tiện ích mở rộng Manifest V3 của Chrome gồm 32 ký tự được lấy từ đúng mười sáu chữ cái đó, nên bước kiểm tra nhận diện đúng hình dạng của một origin tiện ích mở rộng thật. Lỗi nằm ở chỗ mọi tiện ích mở rộng đều có hình dạng đó. Bước kiểm tra chỉ hỏi liệu bên gọi có trông giống một tiện ích trình duyệt hay không, chứ không bao giờ hỏi liệu nó có phải là tiện ích trình duyệt của dự án này, và định danh mà nó lẽ ra phải so sánh thì đã công khai: README của dự án liên kết đến trang niêm yết trên Chrome Web Store, có ID là hhcmgoofomhgciiibhipgmgkgnoenaoi, và ID Edge Add-ons bên cạnh. Không chuỗi nào trong hai chuỗi đó xuất hiện ở bất kỳ đâu trong cổng kiểm tra.

Daemon lắng nghe trên một cổng cục bộ cố định, 52800, được khai báo là DEFAULT_WS_PORT trong CLI và được sử dụng không thay đổi trong đường kết nối cục bộ. Cổng này được ghi tài liệu, không đổi và có thể truy cập được bởi bất kỳ thứ gì đang chạy trong hồ sơ trình duyệt của người dùng. Vị trí là lý do vectơ của bản tư vấn bắt đầu bằng AV:L — kẻ tấn công cần một chỗ đứng trên máy, và PR:L ghi nhận rằng một chỗ đứng đặc quyền thấp là đủ. Một tiện ích mở rộng được cài trong cùng hồ sơ chính là kiểu chỗ đứng như vậy.

Chỗ ngồi đáng giá bao nhiêu, và bao nhiêu phần trong đó đã được xác lập

Câu mô tả tác động của khuyến cáo mang tính rộng: kẻ tấn công đăng ký một tiện ích mở rộng độc hại làm ứng dụng khách trình duyệt có thể "chặn và thao túng nội dung trang, DOM và ảnh chụp màn hình được trả về cho tác nhân AI." Đó là mô tả mà CVE, bản ghi khuyến cáo GitHub GHSA-x6f2-qp26-2xrh và kho lưu trữ đều có, và nó giải thích xếp hạng toàn vẹn CVSS ở mức cao. Đây cũng là bản tóm tắt do bên đã gán CVE viết, không phải báo cáo về một cuộc tấn công đã được chứng minh.

Một bản tường thuật cẩn thận hơn xuất hiện cùng tuần đó, ngay trong chính chuỗi thảo luận của issue. Vào 20 tháng 9, một người bình luận đăng với tên bb6894 cho biết đã kiểm tra lại mã nguồn so với main tại commit fa953dc6 (18 tháng 9) và lần theo những gì một client lạ thực sự có thể chạm tới sau handshake. Hầu hết các phương thức công cụ gửi vào, theo bình luận, đều trả về UnknownMethod cho một peer WebSocket; các yêu cầu audit bị giới hạn trong hồ sơ của chính client; và các hành động xuyên phiên như window_closed, user_interrupt và update_interaction được bảo vệ chống lại các phiên thuộc sở hữu của một trình duyệt khác. Thứ vượt qua bộ lọc đó hẹp hơn và, đối với một agent, có thể nói là tệ hơn cả việc bị chặn bắt: một tiện ích mở rộng lạ có thể chiếm một slot trình duyệt dưới instance_id do kẻ tấn công chọn, và nếu nó là trình duyệt duy nhất được đăng ký — khởi động nguội hoặc khởi động lại daemon — nó nhận các yêu cầu công cụ của agent và trả lời bằng nội dung trang, DOM hoặc ảnh chụp màn hình được ngụy tạo. Người bình luận gọi đây là "giả mạo kết quả nhắm tới agent" và "một kênh vào nhận thức của agent." Một hiệu ứng thứ hai là từ chối dịch vụ: khi cũng có một trình duyệt thật đang trực tuyến và không có selector, quá trình khởi tạo phiên có thể thất bại với MultipleBrowsersOnline.

Cả hai cách lý giải đều chưa từng được chứng minh công khai. Người báo cáo mô tả một bản chứng minh khái niệm là "có sẵn theo yêu cầu"; chưa ai công bố một bản nào, và không có ghi nhận việc khai thác. Vì vậy, khác biệt giữa hai cách lý giải là khác biệt giữa hai cách đọc cùng một tệp nguồn, chứ không phải giữa một lý thuyết và một khai thác hoạt động được — và bài viết trình bày cả hai thay vì chọn một. Điều có thể nói mà không cần dè dặt là không hề có lần kiểm tra danh tính thứ hai nào sau handshake, nên bất cứ thứ gì cổng đã chấp nhận thì vẫn được chấp nhận trong suốt vòng đời của kết nối.

Mã đã biết rồi

Tài liệu gây khó chịu nhất trong hồ sơ này không phải là bản khuyến cáo bảo mật. Đó là chú thích ngay phía trên hàm, được phát hành trong bản phát hành có gắn thẻ mà bản khuyến cáo chỉ đến. Nó đánh dấu khoảng trống là TODO(M10/M12), nêu tên danh sách cho phép mà nó định xây dựng — một tập DaemonConfig::allowed_extension_ids được điền từ tệp cấu hình hoặc luồng ghép cặp — rồi nêu lý do nó bị hoãn lại: “khoảng trống phòng thủ theo chiều sâu có thể chấp nhận được ở thời điểm hiện tại vì việc ghép cặp diễn ra qua popup, nhưng một tiện ích mở rộng được cài ngoài trên cùng một máy hiện đang lọt qua cổng kiểm soát.”

Đọc một cách thẳng thắn, nhóm bảo trì biết cổng đã cho bên gọi nào đi qua, đã ghi lại rằng họ biết điều đó, và vẫn phát hành. Điều đó không làm mức phơi nhiễm lớn hơn so với những gì khuyến cáo bảo mật nêu; nó chỉ làm cho sự việc bớt bất ngờ hơn, và chuyển câu hỏi từ "làm sao việc này lọt qua được bước đánh giá" sang "điều gì lẽ ra đã khiến bản sửa bị trì hoãn trở nên cấp bách". Giả định thiết kế giảm thiểu là có thật và cũng đã được ghi lại: kết nối cục bộ là tùy chọn tham gia. Theo README, người dùng cài tiện ích, mở popup của tiện ích và bật kết nối cục bộ, đồng thời daemon phải đang chạy thì mới có thể tiếp cận được bất kỳ phần nào trong số này. Một hồ sơ đã cài tiện ích nhưng tắt công tắc, hoặc không có daemon bsk nào đang chạy, không phải là mục tiêu đang lắng nghe.

Năm tuần sau, cánh cổng vẫn không thay đổi

Phạm vi bị ảnh hưởng trong hồ sơ là “tính đến 0.3.0”, và đó là phạm vi mà CNA đã ấn định. Đó không phải là điểm kết thúc của câu chuyện trong kho lưu trữ. Bản phát hành CLI 0.3.0 đã được gắn thẻ vào ngày 17 tháng 9 lúc 02:22 UTC; vấn đề đã được ghi nhận cùng ngày lúc 15:14 UTC, tức khoảng mười ba giờ sau. Ba bản phát hành CLI nữa đã ra mắt kể từ đó — 0.3.1 vào ngày 23 tháng 9, 0.3.2 vào ngày 30 tháng 9, và 0.3.3 vào ngày 15 tháng 10 — và hàm origin_allowed() tại mỗi thẻ đó vẫn là cùng một kiểm tra như mô tả ở trên, với TODO vẫn còn ở phía trên nó. Nhánh main cũng chứa nó tính đến ngày 27 tháng 10.

Một bản sửa đã tồn tại, nhưng chỉ dưới dạng đề xuất. Vào 28 tháng 9, một người đóng góp đăng với tên dangzitou đã mở pull request #363 từ một bản fork cá nhân, có tiêu đề "fix(daemon): pin WS origin gate to BrowserSkill's own extension ids." Nó thay thế bài kiểm tra hình dạng bằng việc so sánh với hai ID cửa hàng, và thêm BSK_ALLOWED_EXTENSION_IDS như một đường chấp nhận rõ ràng cho các bản dựng cài ngoài và phát triển, mà ID chưa đóng gói của chúng được suy ra từ đường dẫn cài đặt. Nội dung pull request tuyên bố nó đóng cả đường giả mạo và lỗ hổng từ chối dịch vụ MultipleBrowsersOnline. Tính đến ngày 27 tháng 10, nó vẫn mở và chưa được hợp nhất, và vấn đề vẫn mở mà không có tuyên bố nào từ nhà cung cấp gắn với nó.

Hệ quả thực tế là không có phiên bản nào để nâng cấp lên có chứa bản vá. Bất kỳ ai khuyên “nâng cấp vượt qua 0.3.0” đang khuyên một bước chưa tồn tại: các bản phát hành sau chỉ là muộn hơn, chứ không phải đã được sửa. Phạm vi trong bản ghi nên được hiểu là phạm vi mà CNA đã đánh giá vào ngày 20 tháng 9, chứ không phải là một tuyên bố rằng 0.3.1 và các bản sau đều sạch.

Những gì đã được xác lập, và những gì chưa.

• Đã xác lập: mã nguồn đã phát hành tại thẻ cli-v0.3.0 chứa một cổng origin chấp nhận bất kỳ origin chrome-extension 32 ký tự a–p nào. Người báo cáo, CNA và chính tệp đều nhất trí, và mã là công khai.

• Đã thiết lập: cổng chỉ chạy một lần, tại thời điểm nâng cấp WebSocket, không có kiểm tra danh tính nào sau đó, trên một cổng cục bộ cố định 52800.

• Đã xác lập: chú thích trong mã nguồn của chính dự án đã thừa nhận rằng một tiện ích mở rộng được tải ngoài sẽ được chấp nhận, và đã trì hoãn danh sách cho phép.

• Đã xác lập:CVSS 4.0 6.9 và CVSS 3.1 6.6 đều là điểm số của VulnCheck, được NVD ghi nhận là thứ cấp. Trạng thái của chính NVD cho mục nhập này là Deferred, nghĩa là NVD đã công bố dữ liệu của CNA mà không bổ sung phân tích do NVD biên soạn.

• Được xác lập: Đánh giá SSVC của CISA, ngày 21 tháng 9, ghi nhận khả năng khai thác là không, có thể tự động hóa là không, và tác động kỹ thuật là một phần. EPSS của FIRST đặt xác suất khai thác trong ba mươi ngày tới ở mức 0,00135, phân vị thứ 2,9, tính đến ngày 26 tháng 10.

• Chưa được xác lập: bất kỳ mức sử dụng thực tế nào. Không có khai thác, không có bằng chứng khái niệm nào được công bố, không có số lượng bản cài đặt bị ảnh hưởng. Các chỉ số kho lưu trữ của dự án không phải là số lượng bản cài đặt, và chưa ai công bố con số đó.

• Chưa được xác lập: cách giải thích tác động nào là đúng. Việc "chặn và thao túng" của CNA và "giả mạo kết quả cộng với từ chối dịch vụ" của luồng thảo luận mô tả những mức trần tác động khác nhau, và cả hai đều chưa được chứng minh ngoài việc đọc mã.

• Chưa được xác lập: rằng lỗ hổng dừng ở 0.3.0. Chuỗi phiên bản là đánh giá của CNA; mã không thay đổi trong ba bản phát hành sau đó, và không có tuyên bố nào từ nhà cung cấp xác nhận chúng không bị ảnh hưởng.

• Mâu thuẫn, chưa được giải quyết: một trình tổng hợp, DevGuard, hiển thị tín hiệu "đã phát hiện các nỗ lực khai thác" cho CVE này mà không nêu tên nguồn, IOC hay nhà cung cấp dữ liệu đo từ xa. Điều đó trái với đánh giá được ghi nhận của CISA là không có khai thác và trái với việc không có bất kỳ báo cáo công khai nào; kho lưu trữ cũng không ghi nhận khai thác nào. Hãy coi cờ của trình tổng hợp này là không có căn cứ thay vì là một điểm dữ liệu thứ hai.

Vì sao transport lại là mục tiêu đáng quan tâm

Hầu hết hướng dẫn về prompt injection đều vạch ra cùng một ranh giới: coi văn bản trang được truy xuất là không đáng tin cậy, và coi cơ chế truyền tải nó là đáng tin cậy. Một công cụ đọc trang web được cho là đang đọc trang; câu hỏi là trang đó nói gì. Bản ghi này đảo ngược điều đó. Những gì tác nhân nhận được dưới dạng nội dung trang, DOM và ảnh chụp màn hình là bất cứ thứ gì máy khách ở đầu bên kia của một socket cục bộ chọn gửi, và cổng kiểm soát duy nhất trên socket đó đã hỏi một câu mà mọi ứng viên đều có thể trả lời đúng. Nếu máy khách là bên lạ, "xác minh xem trang nói gì" sẽ không còn gì để đối chiếu.

Đó cũng là lý do vì sao mức độ nghiêm trọng lại nằm ở mức như vậy chứ không cao hơn. Cuộc tấn công mang tính cục bộ, giả định rằng một tiện ích mở rộng đã được cài đặt sẵn trong hồ sơ hoặc có mã cục bộ khác, và nó đòi hỏi daemon phải đang chạy với kết nối cục bộ được bật. Những điều kiện đó là bình thường đối với người dùng mà công cụ hướng tới và bất thường đối với mọi người khác. Mức độ nghiêm trọng trung bình của kho lưu trữ và việc ghi nhận không có thiệt hại nào đều nhất quán với hình thái đó: một sự mở rộng thực sự của phạm vi tin cậy đúng tại ranh giới mà thiết kế lẽ ra phải kiểm soát, mà không có bằng chứng cho thấy ai đó đã vượt qua ranh giới ấy.

Lời khuyên thực tiễn hẹp sau đây không phải là một biện pháp giảm thiểu mà bất kỳ ai đã công bố, mà chỉ là ranh giới mà mã để lại. Bởi vì việc tiếp nhận được quyết định một lần tại bắt tay trên một cổng đã công bố, bề mặt có thể truy cập được xác định bởi những tiện ích mở rộng nào được cài đặt trong hồ sơ chạy daemon, và bởi liệu daemon đó và kết nối cục bộ của tiện ích mở rộng có được bật tại thời điểm đó hay không. Cho đến khi một danh sách cho phép ID tiện ích mở rộng được phát hành, hai sự thật đó là toàn bộ cơ chế kiểm soát.

CVE-2026-94111 sẽ già đi theo một trong hai cách. Hoặc là pull request được hợp nhất và bản ghi trở thành một mục ngắn về một lỗ hổng đã biết mà phải mất một thời gian mới được xử lý, hoặc là cùng kiểu kiểm tra đó vẫn còn trong cây mã nguồn sau một năm và mục này được trích dẫn như một ví dụ ban đầu của lớp mà nó thuộc về: không phải một trang mang chỉ thị độc hại, mà là đường ống quyết định trang nào mà tác nhân đang đọc.