Một lỗ hổng Docker mới được công bố, được theo dõi với mã định danh CVE-2026-17106 và có biệt danh là “CopyEscape”, cho phép các container độc hại ghi đè tệp trên máy chủ và trong một số cấu hình nhất định, đạt được quyền thực thi mã root hoàn toàn.
Lỗ hổng này được phát hiện bởi Imperva Red Team và ảnh hưởng đến lệnh docker cp được sử dụng rộng rãi, cùng với lệnh sbx cp liên quan được sử dụng trong Docker Sandboxes cho các quy trình làm việc của AI-agent.
Lỗ hổng CopyEscape: Cơ chế và Tác động
Nếu bị khai thác, CopyEscape cho phép một container độc hại thoát khỏi môi trường cô lập của nó, ghi hoặc ghi đè các tệp tùy ý lên máy chủ client, và trong các điều kiện cụ thể trên hệ thống Linux, đạt được quyền thực thi mã cấp root. Đây là một mối đe dọa nghiêm trọng đến tính toàn vẹn của hệ thống.
Lỗ hổng nằm bên trong quy trình xử lý lưu trữ (archive pipeline) của Docker, cơ chế di chuyển tệp giữa container và máy chủ. Khi người dùng thực thi một lệnh đơn giản như docker cp container:/path/to/file.txt ./file.txt, Docker không thực hiện sao chép trực tiếp hệ thống tệp.
Thay vào đó, daemon sẽ quét hệ thống tệp đang hoạt động của container, đóng gói đường dẫn được chọn vào một tệp lưu trữ tar và chuyển tệp lưu trữ đó cho Docker CLI để giải nén trên máy cục bộ. Thiết kế này dựa trên hai giả định: daemon tạo ra một kho lưu trữ nhất quán và CLI giữ mọi tệp được giải nén bên trong đích mà người dùng đã chọn.
Các nhà nghiên cứu của Imperva đã tìm ra cách phá vỡ cả hai giả định này chỉ trong một thao tác sao chép duy nhất. Cuộc tấn công kết hợp một điều kiện tranh chấp hệ thống tệp (filesystem race condition) với kiểm tra symlink bị lỗi.
Do Docker chỉ khóa trạng thái nội bộ của nó trong quá trình quét kho lưu trữ, chứ không phải các tiến trình đang chạy bên trong container, kẻ tấn công có thể thao túng các tệp trong quá trình quét. Bằng cách sử dụng chuỗi thời gian hoán đổi thư mục, container độc hại đánh lừa trình quét của Docker ghi lại một thư mục, sau đó âm thầm thay thế nó bằng một symlink trỏ ra ngoài đích dự kiến, chẳng hạn như /usr/bin.
Một kiểm tra xác thực trong mã giải nén của Docker kiểm tra một đường dẫn đã được xây dựng nhưng thực tế lại tạo ra một symlink [https://cybersecuritynews.com/claude-code-symlink-import-malicious-repositories/] bằng cách sử dụng một đường dẫn khác, chưa được kiểm tra từ kho lưu trữ. Sự không khớp này cho phép các tệp của kẻ tấn công được đặt ở bất kỳ đâu mà symlink trỏ tới, hoàn toàn bỏ qua sandbox.
Tác động đến các quy trình CI/CD và Phát triển
Vì lệnh docker cp hỗ trợ các tác vụ thông thường như thu thập tạo phẩm xây dựng (build artifacts), nhật ký (logs) và bằng chứng điều tra số (forensic evidence), lỗ hổng này trực tiếp đe dọa các quy trình CI/CD, máy trạm của nhà phát triển và quy trình ứng phó sự cố. Trớ trêu thay, một nhà phân tích lấy bằng chứng từ một container bị xâm nhập để điều tra nó có thể vô tình kích hoạt cuộc tấn công này.
Trên macOS, nơi Docker Desktop chạy daemon của nó bên trong máy ảo, CLI vẫn giải nén tệp cục bộ. Điều này có nghĩa là kẻ tấn công có thể ghi đè các tệp cấu hình khởi động shell, cấu hình SSH, hoặc LaunchAgents để đạt được quyền thực thi mã vào lần tiếp theo một terminal được mở.
Trên Linux, nếu lệnh docker cp chạy với đặc quyền nâng cao, như thường thấy trong tự động hóa, phương thức ghi đè tệp tương tự có thể thay thế các tệp nhị phân hệ thống như runc, chuyển đổi việc ghi đè tệp thành quyền truy cập root ngay lập tức.
Phạm vi ảnh hưởng và Các bản vá
Các nhà nghiên cứu cũng đã xác nhận lỗ hổng này [https://www.imperva.com/blog/copyescape-taking-over-docker-hosts-with-docker-cp/] ảnh hưởng đến lệnh sbx cp của Docker Sandboxes, làm lộ môi trường AI-coding-agent trước rủi ro thoát khỏi đích tương tự khi truy xuất tệp từ các sandbox không đáng tin cậy.
Docker đã vá lỗi này trong Docker Engine và CLI 29.7.2, Docker Desktop 4.86.0 và Docker Sandboxes 0.38.0. Quá trình công bố lỗ hổng này bắt đầu vào tháng 4 năm 2026 và yêu cầu nhiều lần gia hạn để giải quyết các lỗi hồi quy từ bản sửa lỗi trước đó.
Các tổ chức chưa thể nâng cấp ngay lập tức nên tránh chạy lệnh docker cp đối với các container không đáng tin cậy hoặc đang hoạt động, dừng các container trước khi sao chép tệp, loại bỏ việc sử dụng sudo docker cp, và chỉ truy xuất dữ liệu đáng ngờ thông qua các môi trường cô lập, có thể loại bỏ sau khi sử dụng.
Bài học cơ bản là việc giải nén kho lưu trữ tự nó là một ranh giới bảo mật, một ranh giới mà các kiểm tra chuỗi đường dẫn không thể đảm bảo một khi symlink và các thay đổi tệp đồng thời xuất hiện.
