DeepSeek Harness CVE-2026-82533: một tác nhân trong sandbox tự vô hiệu hóa sandbox của chính nó chỉ bằng một lệnh

VulnCheck đã công bố CVE-2026-82533 vào ngày 8 tháng 9 năm 2026: một lỗ hổng bỏ qua xác thực nghiêm trọng cho phép tác nhân lập trình AI tắt sandbox của chính nó bằng một lệnh shell. Phần mềm là DeepSeek Harness, môi trường chạy cục bộ mã nguồn mở của DeepSeek dành cho các tác nhân lập trình, mà theo Cloud Security Alliance đã đạt khoảng 215.000 sao GitHub trong vòng vài tuần; mọi phiên bản trước 0.1.2-alpha.1 đều bị ảnh hưởng. Nó đánh giá liệu bên gọi có phải là cục bộ hay không dựa trên chính header Host của bên gọi, vì vậy một yêu cầu có thể tự nhận là loopback. Do sandbox của nó chỉ hạn chế ghi tệp chứ không hạn chế mạng loopback, một tác nhân bị hạn chế có thể gọi API điều khiển không yêu cầu xác thực của harness trên cổng 3080 và chuyển phiên của mình sang danger-full-access với tính năng phê duyệt bị tắt. VulnCheck chấm điểm 9,4, mức nghiêm trọng; chưa có tuyên bố nào về việc bị khai thác trong tự nhiên. Bản ghi này là một mục trong bộ dữ liệu công khai về các sự cố AI, và Orca AI Incident Archive lưu giữ toàn bộ tập bản ghi, cùng ngày tháng, mức phân loại nghiêm trọng và nguồn cho từng mục.

Bước kiểm tra đã hỏi yêu cầu xem nó là gì

Thành phần dễ bị tổn thương là API điều khiển agent cục bộ của harness, dịch vụ HTTP nhỏ mà giao diện web và dòng lệnh dùng để điều khiển một phiên đang chạy. Theo ghi chú nghiên cứu ngày 10 tháng 9 năm 2026 của Cloud Security Alliance, dựa trên bài viết của OX Security, công ty đã phát hiện lỗ hổng, dịch vụ đó lắng nghe trên 127.0.0.1 cổng 3080 theo mặc định và đưa ra quyết định tin cậy trong một hàm mà ghi chú đặt tên là isTrustedApiRequest. Hàm này đọc header Host của HTTP và cấp quyền truy cập khi giá trị khớp với một tên loopback như localhost hoặc 127.0.0.1. Header Host là siêu dữ liệu do máy khách ghi; nó không cho biết kết nối TCP đến từ đâu. The Hacker News, trích dẫn mã nguồn bị ảnh hưởng vào ngày 9 tháng 9 năm 2026, đưa tin rằng bước kiểm tra chưa bao giờ xem xét nguồn gốc của kết nối và rằng một bình luận trong cùng tệp nói rằng bước kiểm tra "không phải là một lớp xác thực."

Đó chính là toàn bộ CWE-807, việc dựa vào các đầu vào không đáng tin cậy trong một quyết định bảo mật, và đó là điều mà bản ghi đã công bố của VulnCheck mô tả: một tiêu đề Host loopback do máy khách cung cấp được chấp nhận thay cho việc xác thực nguồn gốc thực tế của kết nối TCP.

Điều đã biến một bước kiểm tra tồi thành lối thoát chính là việc harness trao cho tác nhân những chiếc chìa khóa của chính nó. Hacker News đưa tin rằng harness truyền cho shell của tác nhân địa chỉ của giao diện điều khiển và mã định danh của phiên hiện tại, nên một lệnh không phải tự tìm ra cả hai. Trong khi đó, sandbox chỉ bao phủ một kênh mà không bao phủ kênh còn lại: tài liệu tham chiếu dòng lệnh cho bản phát hành bị ảnh hưởng nói rằng theo thiết lập mặc định, các thao tác ghi vẫn nằm trong workspace và các thư mục tạm, còn các thao tác đọc và truy cập mạng thì không bị giới hạn.

Vì sao các lời nhắc phê duyệt không ngăn chặn được nó

Harness đúng là có lời nhắc phê duyệt, và chúng không phải bị vượt qua mà đúng hơn là không áp dụng được. Hacker News đưa tin rằng trong bản phát hành bị ảnh hưởng, việc phê duyệt chỉ được yêu cầu khi một lệnh tìm cách truy cập rộng hơn quyền mà phiên đã có. Lệnh nâng quyền không hề nhằm mục đích đó; nó đã thay đổi cài đặt của phiên. Một tác nhân đã chạy lệnh đó đã chuyển sang chế độ mà OX Security gọi là danger-full-access, với lời nhắc phê duyệt được đặt thành never, và tiếp tục chạy với tư cách người dùng đã khởi chạy harness, hoàn toàn bên ngoài sandbox.

Bằng chứng của OX Security về ranh giới này là một cặp đối chứng có kiểm soát. The Hacker News đưa tin rằng công ty đã chạy hai phiên với cùng cài đặt mặc định giống hệt nhau và cấp cho cả hai cùng một lệnh: phiên thực hiện cuộc gọi đã ghi vào một thư mục bên ngoài không gian làm việc của nó, còn phiên kia thì bị chặn.

Con đường thứ hai, và điều kiện tiên quyết mà nó cần

Cùng một kiểm tra bị thiếu đã khiến harness lộ diện với những bên gọi vốn chưa từng ở trong sandbox, nhưng chỉ trong một điều kiện mà cấu hình mặc định không tạo ra. Dòng lệnh từ chối liên kết API với mọi giao diện mạng, vì vậy cổng chỉ có thể truy cập từ nơi khác nếu người dùng đã chuyển tiếp nó — qua đường hầm, proxy ngược, chuyển tiếp SSH hoặc tính năng chuyển tiếp cổng của chính trình soạn thảo, theo The Hacker News; ghi chú của Cloud Security Alliance liệt kê cùng tập hợp đó. Khi điều kiện tiên quyết đó đúng, theo cảnh báo của VulnCheck, một bên gọi không có thông tin xác thực có thể tạo phiên, thực thi lệnh tùy ý và đánh cắp các bản ghi hội thoại đã lưu. The Hacker News bổ sung rằng cùng giao diện đó đáp ứng một yêu cầu tải xuống toàn bộ nhật ký của một phiên.

Lộ trình trong sandbox cần một điều kiện tiên quyết khác: văn bản mà tác nhân sẽ đọc và hành động dựa trên đó. Ghi chú của Cloud Security Alliance mô tả một tác nhân bị giới hạn đang xử lý một lời nhắc do kẻ tấn công cung cấp, được nhúng trong bình luận mã, tệp README hoặc nội dung issue. Cả hai lộ trình đều không yêu cầu khóa bị đánh cắp, và ghi chú nhận định rằng lộ trình từ xa không cần tương tác với mô hình chút nào sau khi cổng bị lộ.

Như vậy, nhóm người dùng bị phơi nhiễm là bất kỳ ai đã chạy harness ở phiên bản 0.1.1-rc.2 hoặc sớm hơn với cấu hình mặc định, một tập hợp mà số lượng sao chỉ phản ánh phần nào. Hacker News đếm được hơn 216.000 sao vào ngày 9 tháng 9 năm 2026 và lưu ý rằng một ngôi sao là một dấu trang chứ không phải một lượt cài đặt.

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

Được xác lập, từ chính bản ghi CVE: VulnCheck là cơ quan cấp số, đã bảo lưu mã định danh vào ngày 29 tháng 8 năm 2026 và công bố bản ghi vào ngày 8 tháng 9 lúc 16:59 UTC; điểm yếu là CWE-807; phạm vi bị ảnh hưởng là mọi phiên bản trước 0.1.2-alpha.1; và ghi nhận công lao thuộc về Nir Zadok và Moshe Siman Tov Bustan. Hai điểm số mà bản ghi mang, 9.4 theo CVSS 4.0 và 9.6 theo CVSS 3.1, đến từ VulnCheck chứ không phải từ một bên chấm điểm thứ hai, độc lập — NVD liệt kê cả hai chỉ số với VulnCheck là nguồn của chúng — vì vậy chúng là một đánh giá được diễn đạt bằng hai khung, không phải hai đánh giá đồng thuận.

Đã xác nhận từ kho lưu trữ: commit sửa lỗi 3e24087, có tiêu đề "fix(web): authenticate the browser Host API," được ghi ngày 24 tháng 8 năm 2026 và bổ sung một mô-đun xác thực trình duyệt cùng với 210 dòng kiểm thử đầu-cuối cho luồng mới, theo GitHub API. Bản phát hành được gắn thẻ dsh-v0.1.2-alpha.1 tiếp theo vào ngày 27 tháng 8 lúc 17:06 UTC.

Chưa được xác lập: sử dụng. Cả bản ghi CVE, khuyến cáo của VulnCheck, lẫn ghi chú phát hành của DeepSeek đều không mô tả việc bị khai thác trong thực tế, và NVD ghi nhận mức độ trưởng thành khai thác là không được định nghĩa. Mô hình EPSS của FIRST đã cho lỗ hổng xác suất bị khai thác là 1,24% trong 30 ngày tiếp theo, ở phân vị thứ 68,9, trong nguồn dữ liệu ngày 27 tháng 10 năm 2026. Kho lưu trữ không ghi nhận tác hại thực tế nào cho mục này và chấm cho mục này độ tin cậy A, được ghi chép đầy đủ, với các nguồn sơ cấp đều đồng thuận.

Các ngày tháng, bao gồm hai báo cáo được đưa ra đầu tiên

Hai nhà phát triển đã đi đến cùng một kết luận trước khi có một CVE để chỉ vào. The Hacker News đưa tin về một bài đăng trên bảng thảo luận của chính dự án vào ngày 13 tháng 8 năm 2026 cho thấy một tiến trình vẫn bị giới hạn bởi sandbox đã chạm tới giao diện cục bộ và chuyển phiên sang danger-full-access, kèm đầu ra kiểm thử, và một bài đăng thứ hai vào ngày 14 tháng 8 liệt kê các yêu cầu mà giao diện đó chấp nhận mà không cần thông tin xác thực. Bài đăng thứ hai cũng lưu ý rằng dự án không có tệp chính sách bảo mật và không có kênh riêng để báo cáo lỗ hổng; The Hacker News đã kiểm tra vào ngày 9 tháng 9 và thấy tệp chính sách bảo mật vẫn chưa có.

Dòng thời gian của OX Security đặt báo cáo của mình gửi VulnCheck vào ngày 24 tháng 8 năm 2026 — cùng ngày mà GitHub ghi nhận cho commit sửa lỗi. Thông điệp commit không đề cập gì đến báo cáo đó, và bài tường thuật công khai của OX Security, như The Hacker News mô tả, không nhắc đến các bài đăng cộng đồng trước đó. Liệu hai sự kiện vào ngày 24 tháng 8 có liên quan với nhau hay không là điều hồ sơ công khai không nêu rõ, và bài viết này không giả định như vậy.

Khoảng cách giữa bản vá và công bố không có gì lạ. Ghi chú của Cloud Security Alliance ghi lại rằng OX Security đã xác nhận bản vá vào ngày 30 tháng 8, chín ngày trước khi VulnCheck công bố CVE.

Nơi bản vá đã được áp dụng, và nơi nó chưa được áp dụng

Thẻ GitHub và registry gói không di chuyển cùng nhau, và đó là phần đáng biết nếu bạn đã cài harness theo cách mà hướng dẫn của nó đề xuất. Gói dòng lệnh, @deepseek-ai/dsh, đã phát hành 0.1.1-rc.2 vào ngày 21 tháng 8 năm 2026 và sau đó không có gì cho đến 0.1.2-alpha.2 vào ngày 30 tháng 8. Phiên bản 0.1.2-alpha.1, phiên bản mà CVE nêu là bản sửa lỗi, hoàn toàn vắng mặt khỏi registry, vì vậy bản phát hành đã sửa lỗi có thể cài đặt đầu tiên chậm hơn bản sửa lỗi ba ngày. Siêu dữ liệu registry npm được đọc cho bài viết này vào ngày 28 tháng 10 năm 2026; The Hacker News đã đưa tin về khoảng trống tương tự vào ngày 9 tháng 9.

Ghi chú phát hành không trình bày đây là bản phát hành bảo mật. Trong số các thay đổi thường lệ, họ liệt kê rằng giao diện web giờ đây yêu cầu xác thực bằng token dùng một lần để truy cập qua mạng, không có tham chiếu CVE và không có thông báo bảo mật, và The Hacker News đã không tìm thấy khuyến nghị bảo mật nào trong danh sách khuyến nghị của kho lưu trữ vào ngày 9 tháng 9. Cơ chế này, như Cloud Security Alliance mô tả: harness in một token dùng một lần khi khởi động, trình duyệt đổi token đó lấy một cookie đã ký, và mọi lệnh gọi tiếp theo đều phải xuất trình cookie — sự tin cậy được ràng buộc với một bí mật được phát hành khi tiến trình khởi động thay vì với một nguồn mạng được tuyên bố.

Các bản dựng bên thứ ba là khâu còn bỏ ngỏ. Các lớp bọc desktop tự đóng gói bản sao harness của riêng mình, vì vậy việc người dùng đang chạy phiên bản nào là do người duy trì lớp bọc quyết định; The Hacker News đã phát hiện một bản dựng Windows được ghim ở 0.1.1-rc.2 vào cuối tháng 8, sau đó chuyển sang 0.1.3-alpha.1 — bản có chứa bản sửa lỗi — vào ngày 6 tháng 9.

Bản thân sandbox không thay đổi. Khi đọc tài liệu tham chiếu dòng lệnh 0.1.2-rc.1, The Hacker News thấy cùng một tuyên bố rằng quyền đọc và truy cập mạng không bị hạn chế, và thấy rằng shell của agent vẫn nhận được địa chỉ giao diện. Không nguồn nào trong bài báo cáo đó cho biết liệu một agent làm việc bên trong workspace của nó vẫn có thể có được một phiên hợp lệ theo cơ chế mới hay không, một câu hỏi mà tài liệu của chính bản vá để ngỏ.

Các nguồn của hồ sơ khuyến nghị điều gì

• Coi mọi bản cài đặt ở phiên bản 0.1.1-rc.2 hoặc sớm hơn là bị ảnh hưởng, bất kể được đóng gói như thế nào, kể cả bản sao được nhúng trong một lớp bọc desktop.

• Cài đặt 0.1.2-alpha.2 hoặc mới hơn từ npm; phiên bản mới nhất trên registry vào ngày 27 tháng 10 năm 2026 là 0.2.2-alpha.2.

• Nếu bạn không thể nâng cấp, hãy dừng giao diện web khi không sử dụng và gỡ bỏ mọi tunnel, proxy hoặc chuyển tiếp cổng có thể truy cập tới cổng 3080.

• Kiểm tra xem cổng 3080 có thể truy cập được từ bất kỳ đâu khác ngoài loopback hay không, bao gồm cả chuyển tiếp cổng container, reverse proxy và đường hầm SSH.

• Ghi nhật ký các thay đổi leo thang đặc quyền và chế độ phê duyệt ở cấp harness, vì cuộc tấn công đã thành công nhờ làm cho một thao tác leo thang trái phép trông giống như hoạt động thường ngày.

Cả năm thông tin đều đến từ ghi chú của Cloud Security Alliance và bài đưa tin của The Hacker News; bản thân bản ghi CVE không có hướng dẫn khắc phục nào ngoài phiên bản đã được sửa.

Vì sao Cloud Security Alliance lại xem đó là một mẫu

Bản ghi chú của Cloud Security Alliance đặt CVE này bên cạnh hai thất bại ngăn chặn tác nhân lập trình khác mà tổ chức đã ghi nhận trong năm 2026: GuardFall vào ngày 1 tháng 7, trong đó mười trong số mười một tác nhân lập trình mã nguồn mở phổ biến có thể bị dụ chạy các lệnh shell mà rào chắn của chúng vốn được xây dựng để chặn, và các phát hiện về chuyển giao tin cậy ngày 22 tháng 7, trong đó một tác nhân bị giới hạn đã ghi một tệp mà một thành phần đáng tin cậy bên ngoài hộp cát sau đó thực thi. Bản ghi chú nêu rõ rằng cả ba đều đến từ nghiên cứu của chính tổ chức chứ không phải từ một khảo sát toàn diện thị trường, và rằng liệu mô hình này có khái quát hóa vượt ra ngoài các tác nhân mà tổ chức đã kiểm tra hay không thì chưa được xác lập. Điều mà bản ghi chú lập luận là các thất bại nằm ở những tầng khác nhau — rào chắn lệnh, tin cậy hạ nguồn, và giờ là xác thực mặt phẳng điều khiển — và đó là lý do tổ chức khuyến nghị coi kiến trúc hộp cát là một câu hỏi mua sắm thay vì một yêu cầu đã được đáp ứng.

Tài liệu an toàn của chính DeepSeek không mâu thuẫn với cách hiểu đó. Tệp SAFETY.md trong kho mã nêu rằng phần mềm "chưa trải qua kiểm toán bảo mật và không được coi là an toàn hoặc sẵn sàng cho môi trường sản xuất", đồng thời việc sandbox, lời nhắc phê duyệt và các kiểm soát quyền "không bảo đảm cách ly hay ngăn chặn thiệt hại". Lỗ hổng xác thực khiến một tác nhân có thể thoát ra ngoài qua API điều khiển đã được đóng trong các bản dựng hiện tại. Sự bất đối xứng khiến đường thoát đó ngắn — một ranh giới quanh thao tác ghi và không có gì quanh mạng — vẫn là một hạn chế được nêu rõ của sandbox chứ không phải lỗi mà bản vá đặt ra để khắc phục.