Lỗ hổng Docker mới: Bỏ qua mọi kiểm soát chỉ với một payload đơn giản

Một lỗ hổng CVE nghiêm trọng mới được phát hiện trong Docker Engine có thể cho phép kẻ tấn công vượt qua các plugin ủy quyền và tiềm ẩn nguy cơ giành quyền truy cập trái phép vào hệ thống máy chủ cơ bản.

CVE-2026-34040 (CVSS 8.8) cho phép bất cứ ai bypass hoàn toàn plugin kiểm soát quyền (AuthZ) trên Docker Engine và chiếm đoạt đặc quyền root trên máy chủ vật lý, chỉ thông qua một HTTP POST request có kích thước lớn hơn 1MB. Sự bùng nổ hiện tại của mô hình AI Coding Agent hoạt động bên trong các Docker Sandboxes đã biến sai lầm thiết kế 10 năm tuổi này thành đòn bẩy chết người, cho phép đánh cắp rò rỉ mã nguồn và AWS Identity từ sâu trong lõi hạ tầng doanh nghiệp.

Tóm tắt rủi ro

Lỗ hổng CVE-2026-34040 trên Docker Engine cho phép kẻ tấn công hoặc các AI Agent vượt qua hoàn toàn cơ chế kiểm soát quyền (Authorization Plugins) bằng cách gửi một HTTP request có kích thước lớn hơn 1MB. Hậu quả là kẻ tấn công có thể tạo một privileged container và chiếm quyền root trên hệ thống máy chủ vật lý, đánh cắp AWS credentials, SSH keys hay Kubernetes configs mà không cần khai thác mã phức tạp.

Rủi ro này tác động trực tiếp đến 92% hạ tầng doanh nghiệp đang dùng Docker, đặc biệt trong các môi trường triển khai CI/CD hoặc các AI coding sandboxes đang ngày càng thịnh hành. Vấn đề nằm ở thiết kế "fail-open" của middleware AuthZ trong suốt 10 năm qua.

Mô tả lỗ hổng & Phạm vi ảnh hưởng

CVE ID: CVE-2026-34040

CVSS v3.1: 8.8 (High)

CWE: CWE-863 (Incorrect Authorization)

Môi trường ảnh hưởng:

Docker Engine: Tất cả các phiên bản từ v1.10 (ra mắt tháng 2/2016) đến trước v29.3.1.
Docker Desktop: Các phiên bản cũ hơn v4.66.1 (bản 4.66.1 đã bao gồm Engine 29.3.1).
Mirantis Container Runtime (MCR): Bao gồm phiên bản MCR mới nhất (v29.2.1) ở thời điểm phát hiện lõi (MCR dùng chung upstream Moby với Docker Engine nên cũng chia sẻ rủi ro này).
Hệ thống KHÔNG bị ảnh hưởng: Các cụm Kubernetes sử dụng containerd hoặc CRI-O (mặc định từ K8s v1.24), cũng như Podman. Lỗi này đặc thù nằm trong frame AuthZ nội bộ của Docker.

Điều kiện: Hệ thống Docker phải phụ thuộc vào tính năng AuthZ plugins (ví dụ Open Policy Agent - OPA, Prisma Cloud, Casbin) để chặn các hành vi tạo container nguy hiểm, và port Docker API được phơi bày trực tiếp (hoặc gián tiếp qua sandboxes).

Attack vector: Network / Local — Không cần tương tác từ người dùng, đặc quyền thấp. Kẻ tấn công hoặc agent chỉ cần gửi một API request chứa padding đẩy dung lượng vượt ngưỡng giới hạn.

Kiến trúc Docker và "Người gác cổng" AuthZ

Để hiểu rõ vì sao chặn sai kích thước lại dẫn tới chiếm quyền máy chủ, chúng ta cần nhìn vào kiến trúc cốt lõi của Docker.

Không giống như các máy ảo (Virtual Machine - VM) sở hữu kernel độc lập, container của Docker vận hành bằng cách chia sẻ chung một kernel duy nhất của hệ thống host vật lý. Sự cách ly (isolation) giữa chúng hoàn toàn là các lớp tường thành ảo được cấu trúc nhờ vào tính năng của Linux (cgroups, namespaces). Nếu bức tường này bị phá, bất kỳ thứ gì có trong container sẽ lập tức có đặc quyền truy cập tới hệ thống bên dưới.

Nhằm bảo vệ hệ thống, trong môi trường Enterprise, các tổ chức thiết lập quy định: không phải ai hay tác vụ nào cũng được phép tạo container. Quá trình kiểm soát này được giao cho các AuthZ Plugins (Authorization Plugin).

Mọi REST API request gửi tới Docker Engine (như POST /containers/create) đều đi qua một trạm trung chuyển (AuthZ middleware). Middleware đóng vai trò đọc nội dung, gói lại và đưa cho AuthZ Plugin xét duyệt. Nếu AuthZ phát hiện payload định tạo container có cờ nguy hiểm (như Privileged: true hoặc map quyền root), nó sẽ chặn đứng request. Lỗ hổng CVE-2026-34040 xảy ra không phải do AuthZ kém thông minh, mà là do chính trạm trung chuyển đã "giấu" dữ liệu trước khi đưa cho AuthZ.

Cơ chế khai thác

Lỗ hổng xuất phát từ cách Docker AuthZ middleware xử lý dữ liệu đầu vào. Từ phiên bản 1.10 (phát hành đầu 2016), Docker sử dụng hằng số maxBodySize = 1048576 (tương đương 1MB).

Khi nhận được request (như POST /containers/create), nếu kích thước body của request nhỏ hơn 1MB, toàn bộ nội dung sẽ được gói và gửi tới AuthZ plugin để kiểm tra (ví dụ xem có cờ Privileged: true không). Tuy nhiên, nếu body vượt quá 1MB, middleware sẽ áp dụng logic cắt gọt (drainBody) và đẩy một RequestBody: nil đến AuthZ.

Vì plugin nhận được payload rỗng, nó không thấy lý do gì để từ chối và mặc định trả về kết quả "cho phép". Tuy plugin bị cắt luồng input, Docker daemon phía sau lại xử lý toàn bộ payload thực tế, bao gồm cả nội dung độc hại. Đáng chú ý, bản chất lỗi này là một việc vá lấp không hoàn chỉnh cho CVE-2024-41110 (lỗ hổng khai thác qua body 0-byte từ năm 2024).

Kẻ thù không cần dùng bất kỳ kỹ xảo binary exploit nào. Chỉ cần chèn thêm một field dữ liệu rác dài khoảng 2MB vào cục JSON, lệnh tạo container với quyền root mount thẳng hệ thống /host vẫn chui lọt.

Phân tích kỹ thuật PoC

Để hình dung rõ hơn, dưới đây là phân tích chi tiết payload cấu thành PoC lợi dụng lỗ hổng này. Một API request nguyên bản để tạo privileged container thường có cấu trúc nhỏ gọn và sẽ ngay lập tức bị AuthZ Plugin chặn lại:

Tuy nhiên, trong PoC thực tế, kẻ tấn công (hoặc mã độc do AI Agent thực thi) sẽ chèn thêm một trường (field) vô thưởng vô phạt nhưng có độ dài cực lớn vào cấu trúc JSON. Field này bị Docker Engine parser bỏ qua do không mang ý nghĩa cấu hình, nhưng lại có tác dụng tĩnh học là thổi phồng Content-Length của HTTP request vượt ngưỡng 1 Megabyte:

Quá trình xử lý trót lọt của Docker Engine đối với payload này:

Middleware tiếp nhận: Middleware nhận thấy Content-Length báo hiệu gói tin ~1.5MB (cao hơn định mức 1048576). Hàm drainBody kích hoạt, chủ động từ chối copy phần body này gửi cho trạm AuthZ nhằm mục đích hạn chế tràn RAM.

AuthZ Plugin bị làm mù: Trạm kiểm duyệt AuthZ Plugin vấp phải HTTP payload rỗng từ middleware đưa lên (len=0). Do không nhìn thấy keyword Privileged: true hay các chỉ định độc hại, AuthZ không thể đối chiếu với list chặn và tự động trả về "Allow" do thiết kế "fail-open".

Docker Daemon Core thực thi: Khác trạm kiểm duyệt, kiến trúc lõi phía sau lại nhận xử lý nguyên vẹn body nặng 1.5MB nguyên thủy gửi từ client. Nó parse cấu trúc JSON thành công và phớt lờ trường rác AuthZ_Bypass_Padding. Lệnh tạo container được cấp phép, kéo theo vùng chứa có đặc quyền (privileged) mapping tới thư mục root /:/host_root để đối tượng đánh cắp secrets hệ thống.

Ghi nhận khai thác thực tế

Hiện điểm CVSS là 8.8 thay vì 10.0 phụ thuộc vào nhận định "cần có Local access" lên Docker socket. Nhưng với sự phủ sóng của AI Agents (như OpenClaw), bối cảnh đã thay đổi.

AI Coding Agent chạy trong Docker Sandboxes thường được mount sẵn quyền truy cập Docker daemon để tiện spin up môi trường test. Cyera Research đã trình diễn PoC chuỗi tấn công (kill chain) cực kỳ thực tế:

Kẻ tấn công tạo một repo dính Prompt Injection trên GitHub.

Developer yêu cầu Agent tự clone repo xuống.

Agent dính độc, tự dùng Python gửi REST request > 1MB tới Docker socket nội bộ.

Nó tạo thành công một privileged container, đọc nội dung /host/root/.aws/credentials rồi gửi ra ngoài.

Thậm chí không cần chủ đích phá hoại, các Agent (như Claude Code) thường xuyên tìm cách vượt blocklist để "giải quyết task". Việc vượt rào này giờ đây quá đơn giản qua một payload bị làm phình to. Ở cấp độ hạ tầng, các repo phần mềm độc hại chèn lệnh qua npm postinstall (tương tự chiến dịch nhắm vào Axios hồi tháng 3/2026) hoàn toàn có thể tự kích hoạt quy trình này.

MITRE ATT&CK Mapping

Tactic	Technique	Mô tả
Execution	T1059.006 - Python	Dùng Python script để chuẩn bị request
Execution	T1610 - Deploy Container	Tạo container lậu để bypass AuthZ gate
Privilege Escalation	T1611 - Escape to Host	Thoát sandbox bằng quyền privileged container
Credential Access	T1552.001 - Credentials In Files	Trích xuất AWS config thẳng từ disk của máy host
Lateral Movement	T1078 - Valid Accounts	Dùng credentials để xâm nhập vào Cloud/K8s

IOC

Lọc lại tất cả các container đang chạy với quyền nhạy cảm:

docker inspect --format '{{.Name}} Privileged={{.HostConfig.Privileged}} Binds={{.HostConfig.Binds}}' $(docker ps -aq)

Nếu tìm thấy container sở hữu Privileged=true và Binds=[/:/host] trong khoảng thời gian có cảnh báo kích thước body, hệ thống gần như chắc chắn đã bị compromise.

Response steps:

Export logs và forensic image của container khả nghi.

Xóa các token (AWS, Azure, K8s) có thể đã bị rò rỉ nếu mount /host thành công.

Patch lên Docker 29.3.1 ngay lập tức.

Nhận định

CVSS 8.8 High hoàn toàn phản ánh đúng hậu quả của sự cố. Theo quan sát của đội ngũ chuyên gia FPT IS SOC, rủi ro lớn nhất trên các hệ thống doanh nghiệp Việt Nam hiện nay không phải là Docker bị phơi ra Internet, mà là bề mặt tấn công rộng mở từ các công cụ CI/CD (GitLab Runner, Jenkins) hay môi trường sandbox dành cho phát triển ứng dụng nội bộ. Rất nhiều tổ chức công nghệ và tài chính tại Việt Nam đang có xu hướng ứng dụng AI/LLMs xử lý code nội bộ; lỗ hổng này biến chính các "trợ lý AI" đó thành những kẻ cắm cổng gián điệp, khi chúng âm thầm bypass hàng rào AuthZ mà không một cảnh báo truy cập bất hợp pháp nào được ghi nhận trên plugin theo dõi.

Sâu xa hơn, cấu trúc giới hạn maxBodySize đã tồn tại 10 năm trong mã nguồn của Docker lại dùng thiết kế "fail-open" (có lỗi thì bỏ qua coi như đúng). Đây là một sai lầm chết người cho bất kỳ kiến trúc middleware bảo mật nào. Cú vấp trước đây qua lỗ hổng CVE-2024-41110 (content-length = 0) là tín hiệu, và CVE lần này là bản kết luận: Không thể phó thác sự an toàn của kernel qua những chốt chặn xử lý dữ liệu nhập nhằng.

Khuyến nghị hành động

Immediate (0-24h)

Kiểm tra phiên bản Docker Engine: Chạy lệnh docker version --format '{{.Server.Version}}'.
Bổ sung luật chặn (WAF/Reverse Proxy) với các Endpoint nhạy cảm: Áp dụng client_max_body_size 512k ở Nginx trước API của Docker socket đối với endpoint /v[\d.]+/(containers/create|exec/.+/start).

Short-term (1-7 ngày)

Cập nhật phiên bản Docker Engine lên >= 29.3.1. Bản vá này đã triệt tiêu hàm xử lý cũ, mở rộng limit lên 4MB và thay đổi kiến trúc chặn đứng request (fail-closed) nếu body vượt dung lượng.
- Engine v29 | Docker Docs
- 29.2.1 - Mirantis Container Runtime
Với người dùng Docker Desktop, update lên bản 4.66.1.
- Docker Desktop: The #1 Containerization Tool for Developers | Docker
Nếu không thể nâng cấp ngay, hãy sử dụng Rootless Docker hoặc namespace remapping (--userns-remap). Phương án này giúp giới hạn blast radius ở mức độ user thường nếu privileged container vô tình được gọi.

Long-term

Xem xét lại kiến trúc sandbox tích hợp AI. Sử dụng các reverse proxy riêng cho socket (docker-socket-proxy) để cấm tiệt AI truy cập các API sinh ra container thay vì tin tưởng 100% vào AuthZ plugins.