Container Security: CVEs in Docker and Kubernetes You Should Know

Containers Are Not a Security Boundary

Containers provide isolation, but not the kind you might assume. A container shares the host kernel. A vulnerability in that kernel, in the container runtime, or in the orchestration layer can break the isolation model entirely.

Where Container CVEs Live

Container security vulnerabilities exist at multiple layers. Understanding which layer is affected determines how you respond.

Layer 1: Base Images

Every container starts from a base image, ubuntu:22.04, node:20-alpine, python:3.12-slim. These images contain operating system packages, and those packages have vulnerabilities.

A common mistake: building your container once and never rebuilding it. The base image you pulled 6 months ago may have 50+ known CVEs in its system libraries. Your application code hasn't changed, but your attack surface has grown every day since you built the image.

Mitigation:

• Rebuild images regularly (at least monthly) to pick up base image updates
• Use minimal base images (alpine, distroless, scratch) to reduce the package footprint
• Run trivy image your-image:latest in CI to catch vulnerabilities before deployment
• Pin base image digests, not just tags, to avoid unexpected changes

Layer 2: Application Dependencies

Your package.json, requirements.txt, or go.mod pulls in application-level dependencies that have their own CVEs. These are the same vulnerabilities that affect non-containerized applications, but containers add a wrinkle: the dependency versions are frozen at build time and don't auto-update.

If you built a container with a vulnerable version of express or django, that vulnerability persists in every running instance until you rebuild and redeploy.

Mitigation:

• Run npm audit / pip audit / cargo audit as a CI gate
• Enable Dependabot or Renovate for automated dependency PRs
• Include dependency scanning in your container build pipeline

Layer 3: Container Runtime

The container runtime (Docker Engine, containerd, CRI-O) is the software that actually creates and manages containers. Vulnerabilities here can allow container escape, breaking out of the container into the host system.

Notable examples:

• CVE-2024-21626 (runc): A file descriptor leak allowed container escape. Affected virtually every Docker and Kubernetes installation.
• CVE-2019-5736 (runc): Allowed a malicious container to overwrite the host runc binary, achieving host-level code execution.
• CVE-2020-15257 (containerd): Host network namespace access from a container.

These are the scariest container CVEs because they break the fundamental isolation guarantee.

Mitigation:

• Keep container runtimes updated, this is infrastructure-level patching, not application-level
• Use rootless containers where possible
• Apply seccomp profiles and AppArmor/SELinux policies to limit syscalls
• Monitor the KEV catalog for container runtime CVEs

Layer 4: Kubernetes

If you run Kubernetes, you've added another large attack surface:

• API server vulnerabilities: The kube-apiserver is the brain of the cluster. CVEs here can allow unauthorized access to all resources.
• etcd exposure: etcd stores all cluster state, including secrets. If accessible, an attacker owns the cluster.
• RBAC misconfigurations: Not a CVE per se, but overly permissive roles (especially cluster-admin bound to service accounts) are functionally equivalent.
• Kubelet API: The kubelet on each node can be a lateral movement path if not properly secured.

Notable Kubernetes CVEs:

• CVE-2018-1002105: Privilege escalation through the API server, allowing any authenticated user to gain full cluster admin.
• CVE-2020-8554: Man-in-the-middle attack via malicious ClusterIP services.
• CVE-2021-25741: symlink-exchange attack allowing container escape via subPath mounts.

Mitigation:

• Keep Kubernetes control plane and nodes updated
• Enable and audit RBAC policies regularly
• Restrict network access to the API server and etcd
• Use admission controllers (OPA Gatekeeper, Kyverno) to enforce security policies

A Practical Container Security Checklist

1. Scan images in CI, Trivy, Grype, or Snyk Container before every push to a registry
2. Use minimal base images, Less software means fewer CVEs
3. Rebuild regularly, Monthly at minimum, immediately for critical CVEs
4. Run as non-root, Set USER in your Dockerfile; avoid privileged containers
5. Drop capabilities, Containers don't need SYS_ADMIN, NET_RAW, etc.
6. Set resource limits, Prevent a compromised container from consuming host resources
7. Use read-only filesystems, readOnlyRootFilesystem: true in Kubernetes
8. Monitor for CVEs in your runtime and orchestration layer, These are the highest-impact vulnerabilities

The Container Security Mindset

Containers give you reproducibility and isolation, not invulnerability. Treat every layer, base image, dependencies, runtime, orchestrator, as an attack surface that needs monitoring and patching.

The good news: container environments are highly automatable. Scanning, rebuilding, and redeploying can be fully pipeline-driven. The bad news: if you don't automate it, it won't happen, and your containers will slowly rot into vulnerability-laden artifacts running in production.