Docker Desktop CVE-2025-9074: Khi API nội bộ trở thành cửa ngõ chiếm quyền host
Quá trình phát hiện
Trong một lần quét mạng từ container Docker, Felix Boulet, một nhà nghiên cứu bảo mật tình cờ phát hiện một cổng lạ được mở. Sau khi kiểm tra, anh nhận ra đó là Docker Engine API socket đang chạy mà không có cơ chế xác thực.
Để kiểm chứng, nhóm nghiên cứu thử nghiệm lại trên môi trường Docker Desktop mới:
Windows: khai thác thành công, cho phép leo thang đặc quyền.
macOS: vẫn có rủi ro, nhưng được giảm nhẹ nhờ lớp bảo vệ.
Linux: an toàn hơn vì API không dùng TCP socket.
Bản chất lỗ hổng
Docker Engine API là control-plane của Docker. Nếu bị lộ ra ngoài, bất kỳ ai có quyền truy cập đều có thể làm mọi việc như Docker CLI, ví dụ:
Tạo, xóa, khởi động container
Mount volume từ container khác (truy cập dữ liệu nhạy cảm như database)
Mount toàn bộ hệ thống tệp của host
Điều này đồng nghĩa: attacker có thể đọc, ghi hoặc xóa bất kỳ file nào trên host, bao gồm cả file hệ thống.
Ảnh hưởng theo hệ điều hành
Windows (WSL2): attacker có thể mount ổ C: với quyền admin → truy cập dữ liệu nhạy cảm, ghi đè DLL hệ thống, leo thang lên quyền quản trị viên host.
macOS: Docker Desktop vẫn hỏi quyền khi mount thư mục user, nhưng attacker có thể:
Điều khiển hoàn toàn Docker app/containers
Thay đổi cấu hình Docker không cần xác nhận → cài backdoor lâu dài.
Linux: dùng named pipe thay vì TCP socket, container mặc định không thể truy cập. Chỉ rủi ro khi chạy Docker-in-Docker hoặc cấu hình sai.
Cách khai thác
1. Exploit qua Python
PoC trên macOS chỉ cần 3 dòng Python:
import docker
client = docker.DockerClient(base_url="tcp://192.168.65.7:2375")
client.containers.run("alpine", "touch /mnt/pwned",
volumes=["/Users/<username>/:/mnt"])
Kết quả: tạo file pwned trong thư mục người dùng. Từ đó attacker có thể mở rộng script để làm bất kỳ thao tác nào như Docker CLI.
2. Exploit qua HTTP API
Toàn bộ khai thác chỉ cần 2 request HTTP POST:
B1: Gửi payload JSON tới
/containers/create
→ bind ổ đĩa host (ví dụC:\) vào container tại/mnt/host_root
→ chỉ định lệnh khởi động để đọc/ghi file trên host.B2: Gửi request tới
/containers/{id}/start
→ khởi chạy container, exploit thành công.
3. Exploit qua SSRF
Trong trường hợp ứng dụng web chạy trên container bị dính SSRF, attacker có thể lợi dụng để gửi request đến Docker Engine API (192.168.65.7:2375).
Nếu SSRF hỗ trợ POST/DELETE/PATCH, attacker hoàn toàn có thể tạo container mới, mount volume và chiếm quyền điều khiển host.
Với SSRF chỉ hỗ trợ GET, mức độ rủi ro sẽ thấp hơn, nhưng vẫn có thể dò tìm và xác nhận lỗ hổng.
4. Điều kiện để khai thác
Docker Desktop chạy trên Windows hoặc macOS.
Attacker có quyền chạy container hoặc có thể gửi request tới Docker Engine API (qua SSRF hoặc exposed port).
Mức độ nguy hiểm
Trên Docker Desktop chưa vá lỗi (trước bản 4.44.3), bất kỳ container nào cũng có thể:
Kết nối tới
http://192.168.65.7:2375/mà không cần xác thựcTạo container đặc quyền
Mount ổ đĩa host
Toàn quyền kiểm soát hệ thống Windows/macOS
Bài học rút ra
Không để API quản trị mở mà không xác thực
Phân tách mạng rõ ràng giữa container và host
Áp dụng zero-trust trong toàn bộ môi trường
Kiểm thử bảo mật thường xuyên (bao gồm kiểm tra isolation bằng quét subnet, nmap, fuzzing)
Xem xét triển khai bug bounty/private disclosure để sớm phát hiện các lỗ hổng đơn giản nhưng nguy hiểm
Kết luận và khuyến nghị
Lỗ hổng được gán mã CVE-2025-9074, có CVSS 9.3 (nghiêm trọng).
Đã được vá trong Docker Desktop 4.44.3, yêu cầu người dùng nên nâng cấp Docker tới phiên bản trên
Docker xác nhận rằng Enhanced Container Isolation (ECI) không ngăn chặn được lỗ hổng này.
Đây là ví dụ điển hình cho thấy “API nội bộ không đồng nghĩa với an toàn”.
