CVE-2019-5736 is “one of the most prominent and illustrative vulnerabilities associated with containerization,” and the report shows how that kind of flaw — along with CVE-2022-0492 and CVE-2024-21626 — can turn an isolated container into a path to the host.
Container attack vectors: the five entry points
The research categorizes the primary, actively exploited vectors: (1) vulnerabilities in the host or container runtime; (2) malicious activity inside a compromised container; (3) container escape followed by host compromise; (4) misconfigurations and insecure use of containerization and orchestration APIs; and (5) supply chain attacks such as image poisoning and CI/CD pipeline compromise. These vectors may be used separately or chained together; attackers commonly move beyond a single container to target Kubernetes clusters, secrets stores, and orchestration control planes.
Runtime and kernel vulnerabilities that defeat isolation
Because containers share the host kernel, flaws in runtimes and the Linux kernel are particularly consequential. The report cites runC’s CVE-2019-5736 — which allowed someone with root inside a container to overwrite the runC binary and execute code as host root — and lists CVE-2022-0492, a kernel cgroups release_agent privilege‑validation flaw enabling container escape, and CVE-2024-21626, another runC issue that could expose the host file system or permit full escape via docker exec and similar flows. The central point: the presence of a vulnerability does not guarantee exploitation, but when exploitable it can enable lateral movement, secrets theft, and control of the node or cluster.
Capabilities and misconfigurations: from CAP_SYS_ADMIN to hostNetwork
Misconfiguration, the report emphasizes, is often more common than exotic zero-days. Granting broad Linux capabilities or flags like --privileged erodes isolation. CAP_SYS_ADMIN lets a process mount file systems, alter cgroups, and interact with /proc and /sys; combined with a hostPath mount an attacker can reach host files. CAP_SYS_MODULE allows kernel module loading — the report walks through how a malicious module could be compiled externally, delivered to a container and loaded to spawn a reverse shell. CAP_SYS_PTRACE can permit cross‑process memory access and code injection when host PID namespace is exposed (hostPID: true), and CAP_NET_ADMIN paired with hostNetwork: true can allow iptables manipulation and internal man-in-the-middle activity. These are concrete, high‑risk misconfigurations that expand the blast radius of any initial compromise.
Orchestration API abuse: Docker, kubelet and Kubernetes API examples
Control-plane APIs are powerful and, when exposed or poorly governed, immediately hazardous. An unauthenticated Docker daemon over TCP gives remote actors equivalent admin access to the host; a mounted Docker socket inside a container hands the daemon’s privileges to that container. In Kubernetes, a compromised ServiceAccount token or weak RBAC lets an attacker enumerate permissions and then deploy a privileged pod via the API — the report supplies an example curl POST to create a pod with "securityContext": {"privileged": true} that can be used as the launching point for host escape. The lesson: API access is essentially administrative access to the entire infrastructure.
Supply chain attacks: image poisoning and CI/CD compromise
Rather than attacking runtime directly, adversaries increasingly target the build and distribution stages. The report documents attacks that poison public images on Docker Hub and cites a case where the APT group TeamPCP compromised Checkmarx KICS and poisoned a repository; tainted images distributed a stealer loaded during KICS scanning to extract Kubernetes secrets and other sensitive data. CI/CD systems themselves are attractive targets because build platforms often run with elevated privileges; inserting a single extra command in the pipeline can add a backdoor or drop a binary while leaving the visible application behavior intact.
What this means for technologists, procurement leaders, and defenders
- Technologists and security teams: prioritize configuration auditing, runtime protection, and activity monitoring; minimize container capabilities and avoid hostPath, hostPID, and hostNetwork unless strictly required.
- Procurement and affected enterprises: validate images and CI/CD security across the supply chain; treat build and delivery platforms as high-value assets requiring the same scrutiny as production hosts.
- Defenders and platform operators: assume a compromised container can lead to cluster or host compromise and enforce strict RBAC, authenticated API access, and least-privilege ServiceAccount practices.
The report’s closing observation is direct: securing containerized environments is a multi-layer problem — host protection, strict orchestrator access controls, capability minimization, and end-to-end supply chain validation are all required. To address those needs, the authors note that Kaspersky Container Security was designed to provide protection from images to host systems, helping to implement secure software development principles. The practical question the report leaves for organizations is whether existing controls will be hardened fast enough to keep widely used runtimes, orchestration APIs, and CI/CD pipelines from becoming repeatable attack vectors.
