DeepSeek Harness bị báo cáo lỗ hổng RCE nghiêm trọng: Chỉ một Host Header giả có thể vượt qua lớp bảo vệ /api

QVD-2026-57410 là lỗ hổng nghiêm trọng được báo cáo trong DeepSeek Harness (DSH) phiên bản 0.1.1-rc.2. Các báo cáo liên quan đến QiAnXin mô tả đây là lỗi thực thi mã từ xa (RCE) chưa cần xác thực, với điểm CVSS 3.0 là 9.8. Nguyên nhân cốt lõi nằm ở việc lớp /api có thể dựa vào HTTP Host Header do máy khách kiểm soát để quyết định một yêu cầu có đáng tin cậy hay không — đây là cách thay thế không an toàn cho cơ chế xác thực. 1924

Mức độ rủi ro phụ thuộc đáng kể vào cách triển khai. Theo tài liệu của DeepSeek, lệnh khởi chạy giao diện web thường mở dịch vụ tại 127.0.0.1:3080, giúp hạn chế khả năng truy cập trực tiếp từ xa. Tuy nhiên, rủi ro tăng mạnh nếu dịch vụ được bind vào giao diện mạng không phải loopback, hoặc được chuyển tiếp qua Docker, reverse proxy, tunnel, VPN, mạng LAN hay ingress. 1118

Cơ chế vượt qua kiểm tra Host Header

Thiết kế bị ảnh hưởng cố gắng phân biệt yêu cầu nội bộ và yêu cầu từ xa dựa trên thông tin host của request. Vấn đề là Host Header do chính bên gửi yêu cầu cung cấp và có thể bị giả mạo. Vì vậy, bất kỳ kẻ tấn công nào truy cập được dịch vụ đều có thể gửi một giá trị Host trông giống yêu cầu nội bộ, khiến lớp /api xem request đó là đáng tin cậy. Các báo cáo mô tả đây là hành vi vượt qua ranh giới tin cậy kiểu “chỉ cho phép loopback” của DSH. 1924

Ở mức khái quát, chuỗi tấn công được báo cáo gồm các bước:

1. Truy cập endpoint web hoặc endpoint quản trị DSH đang bị phơi nhiễm.
2. Gửi request với Host Header giả mạo theo kiểu địa chỉ nội bộ.
3. Vượt qua hạn chế của /api, vốn được thiết kế để bảo vệ các thao tác nội bộ.
4. Gọi các chức năng RPC bị giới hạn.
5. Đăng ký hoặc sử dụng một tuyến cung cấp mô hình do kẻ tấn công kiểm soát.
6. Điều khiển khả năng Agent của DSH để thực thi lệnh trên máy chủ. 1920

Đây là lý do lỗi không chỉ dừng ở vấn đề định tuyến hoặc làm lộ thông tin. Điểm cuối bị vượt qua dẫn tới các chức năng được thiết kế để vận hành một AI Agent có khả năng tương tác ở cấp hệ thống.

Vì sao lỗi có thể dẫn tới RCE?

DeepSeek mô tả Harness là phần mềm thử nghiệm dành cho bản xem trước của nhà phát triển và chưa trải qua kiểm toán bảo mật. Thông báo an toàn của dự án cảnh báo rằng Harness có thể thực thi mã, lệnh do mô hình tạo ra, đồng thời truy cập mạng, tiến trình, thông tin xác thực và các tệp được cung cấp cho nó. 4

Phân hệ LLM cũng hỗ trợ đăng ký nhà cung cấp mô hình và khám phá mô hình, trong đó có thao tác từ xa discoverModels. 23 Theo chuỗi khai thác được báo cáo, kẻ tấn công có thể sử dụng một nhà cung cấp do mình kiểm soát để đưa đầu vào cần thiết tới các khả năng thực thi lệnh của Agent. 19

Khai thác thành công không đồng nghĩa với việc kẻ tấn công mặc nhiên có quyền root. Lệnh sẽ chạy với quyền của tiến trình dịch vụ DSH. Dù vậy, các quyền này vẫn có thể đủ để đọc hoặc sửa những tệp mà tài khoản dịch vụ được phép truy cập, sử dụng thông tin xác thực hoặc API key có sẵn, khởi chạy tiến trình, thay đổi dữ liệu ứng dụng hay tạo kết nối ra ngoài.

Tác động cuối cùng phụ thuộc vào cấu hình triển khai — chẳng hạn dịch vụ có quyền truy cập hệ thống tệp quá rộng hay không, container có chạy ở chế độ đặc quyền không, Docker socket có được mount vào container không, hoặc thông tin xác thực đám mây có nằm trong phạm vi truy cập hay không. Các nguồn được cung cấp chưa chứng minh rằng mọi bản cài đặt đều tự động dẫn tới việc chiếm toàn bộ máy chủ.

Những mô hình triển khai nào cần được ưu tiên kiểm tra?

Nhà vận hành nên xem các cấu hình sau là mục tiêu cần rà soát khẩn cấp:

• DSH bind vào 0.0.0.0 hoặc một địa chỉ không phải loopback.
• Docker hoặc runtime container khác công khai cổng 3080 ra ngoài máy cục bộ.
• Reverse proxy chuyển tiếp API quản trị tới Internet hoặc một mạng LAN không đáng tin cậy.
• Tunnel, VPN hoặc ingress khiến dịch vụ có thể được truy cập bởi những người dùng chưa trải qua xác thực mạnh.
• Proxy chấp nhận tùy ý giá trị Host từ máy khách hoặc chuyển nguyên giá trị đó tới máy chủ phía sau.

Một dịch vụ được gọi là “nội bộ” không có nghĩa nó đã được bảo vệ bằng cơ chế phân quyền. Bất kỳ kẻ tấn công nào truy cập được endpoint và tác động tới các header liên quan đều có thể thử thực hiện hành vi vượt qua này.

PoC, trạng thái CVE và bằng chứng khai thác thực tế

Nhiều báo cáo cho biết mã kiểm chứng khai thác (PoC) hoặc các chi tiết kỹ thuật của QVD-2026-57410 đã được công khai. 192027 Điều này làm tăng tính cấp thiết của việc cô lập và xử lý, nhưng việc PoC công khai không phải bằng chứng cho thấy một hệ thống cụ thể đã bị xâm nhập.

Theo các thông tin được cung cấp, tại thời điểm công bố chưa ghi nhận hoạt động khai thác trong thực tế và chưa có bằng chứng liên kết lỗ hổng với một nhóm đe dọa hoặc chiến dịch đã biết. 1924 Đây chỉ là ảnh chụp tình hình tại thời điểm báo cáo, không phải lời đảm bảo rằng các hệ thống đang an toàn. Các phiên bản đang phơi nhiễm vẫn cần được kiểm tra những request bất thường, nhà cung cấp mô hình mới không rõ nguồn gốc, tiến trình lạ và kết nối ra ngoài khác thường.

QVD-2026-57410 là mã định danh QVD, không phải mã CVE. Mã CVE-2026-57410 có số tương tự nhưng đề cập tới một lỗ hổng leo thang đặc quyền không liên quan trong MailerPress, theo cơ sở dữ liệu NVD. 17

Khuyến nghị ứng phó cho nhà vận hành

1. Gỡ dịch vụ khỏi mạng công khai trước tiên

Ngừng công khai dịch vụ quản trị và API của DSH trên Internet. Bind dịch vụ vào loopback hoặc một mạng quản trị riêng. Nếu cần quản trị từ xa, hãy sử dụng VPN được kiểm soát hoặc bastion host.

2. Hạn chế truy cập ở mọi lớp mạng

Áp dụng quy tắc trên firewall, security group của đám mây, mạng container và reverse proxy để chỉ cho phép các nguồn đã được xác định rõ là đáng tin cậy. Không dựa vào một tuyến “nội bộ” hoặc một header trông giống yêu cầu nội bộ như bằng chứng về danh tính.

3. Kiểm tra và ghi đè các proxy header

Tại proxy biên, hãy từ chối các giá trị Host không hợp lệ hoặc không nằm trong allowlist. Khi cần proxy, ghi đè Host gửi tới upstream bằng một giá trị cố định đã biết, thay vì chuyển tiếp mù quáng giá trị do máy khách cung cấp. Chỉ coi các header cho biết IP máy khách là đáng tin khi chúng đến từ một proxy do tổ chức kiểm soát.

4. Bổ sung xác thực độc lập với Host Header

Bảo vệ các thao tác quản trị và RPC nội bộ bằng cơ chế xác thực, phân quyền thực sự — chẳng hạn gateway có xác thực mạnh, mTLS và quyền truy cập theo từng thao tác. Kiểm tra Host Header có thể hữu ích cho định tuyến, nhưng tuyệt đối không được là phương thức duy nhất để xác định danh tính.

5. Giảm rủi ro từ việc khám phá nhà cung cấp và kết nối ra ngoài

Tắt hoặc hạn chế llm.discoverModels nếu không cần thiết. Khi bắt buộc phải sử dụng chức năng khám phá nhà cung cấp, hãy allowlist các endpoint được phép và kiểm soát lưu lượng outbound. Việc chặn truy cập tới các đích nội bộ nhạy cảm và dịch vụ metadata đám mây có thể giảm tác động nếu đường dẫn khám phá nhà cung cấp bị lợi dụng như một cơ chế yêu cầu máy chủ gửi request thay cho kẻ tấn công. Tài liệu LLM của DSH xác nhận rằng đăng ký nhà cung cấp và khám phá mô hình là các khả năng được cung cấp. 23

6. Chỉ coi nâng cấp là biện pháp khắc phục khi có xác nhận chính thức

Các nguồn được cung cấp xác định 0.1.1-rc.2 là phiên bản bị ảnh hưởng và cho thấy dự án đã có các bản phát hành mới hơn, nhưng chưa xác nhận một bản cụ thể nào trong số đó đã sửa lỗ hổng này. Hãy kiểm tra release note và thông báo bảo mật hiện hành của DeepSeek để tìm bản sửa được xác nhận rõ ràng, trước khi xem việc nâng cấp là đủ. Thông báo an toàn của dự án vẫn cảnh báo Harness là phần mềm thử nghiệm và chưa sẵn sàng cho môi trường production. 410

7. Điều tra và thay khóa nếu dịch vụ từng bị phơi nhiễm

Rà soát log của reverse proxy và DSH để tìm request /api bất thường, Host Header giả mạo theo kiểu nội bộ, đăng ký nhà cung cấp mô hình không mong muốn, tiến trình mới, thay đổi tệp và kết nối outbound lạ. Xoay vòng các thông tin xác thực mà tiến trình DSH có thể truy cập. Nếu phát hiện dấu hiệu thực thi lệnh hoặc duy trì quyền truy cập, hãy cô lập và dựng lại máy chủ hoặc container bị ảnh hưởng thay vì cho rằng khởi động lại dịch vụ đã loại bỏ sự xâm nhập.