The Wake-Up Call: CVE-2025-9074

A critical vulnerability recently discovered in Docker Desktop (CVE-2025-9074) serves as a sobering reminder that containers are not the security boundary many developers believe them to be. With a CVSS score of 9.3, this vulnerability allowed malicious containers to escape their supposed isolation and compromise the host system through a surprisingly simple attack vector.

The Bottom Line Up Front: CVE-2025-9074 demonstrates that the widespread belief “Docker = isolated = secure” is not just wrong—it’s dangerously wrong. This misconception puts production Kubernetes environments at risk when teams fail to consider the underlying Linux kernel and operating system security implications.

Understanding CVE-2025-9074: When Isolation Becomes Illusion

CVE-2025-9074 affected Docker Desktop on Windows and macOS, allowing containers to access the Docker Engine API without authentication via a subnet interface (192.168.65.7:2375). The vulnerability bypassed even Enhanced Container Isolation (ECI), demonstrating fundamental flaws in how container isolation was implemented.

The Proof of Concept: Three Lines of Python

Security researcher Felix Boulet showed just how trivial this exploit was:

import docker
client = docker.DockerClient(base_url="tcp://192.168.65.7:2375")
client.containers.run("alpine", "touch /mnt/pwned", volumes=["/Users/<username>/:/mnt"])

This simple script could:

  • Create new containers with host filesystem mounts
  • Access sensitive files on the host system
  • On Windows with WSL2, gain administrator-level access to the entire filesystem
  • Bypass all existing security controls

The attack worked by exploiting an unauthenticated Docker Engine API endpoint that containers could reach through internal networking. No Docker socket mounting was required—the containers could simply make HTTP requests to create new privileged containers with host volume mounts.

The Fundamental Misconception: Containers Are Not Security Boundaries

CVE-2025-9074 highlights a broader, systemic problem in how the industry perceives container security. The core misconception is simple but dangerous:

Myth: “If I put my application in a Docker container, it’s automatically more secure.”

Reality: Containers provide process isolation and resource management, not security boundaries.

Why This Misconception Persists

The misconception stems from several factors:

Marketing and Documentation: Container platforms often emphasize “isolation” without clearly distinguishing between process isolation and security isolation.

Virtualization Background: Developers coming from VM environments expect similar security properties from containers, not realizing containers share the host kernel.

Abstraction Confusion: The containerization abstraction makes it easy to forget that containers run directly on the host Linux kernel with shared system resources.

Default Configurations: Out-of-the-box container configurations prioritize ease of use over security, creating a false sense of safety.

How Container “Isolation” Actually Works (And Where It Fails)

Understanding why containers aren’t secure by default requires examining the Linux kernel features that provide isolation:

Linux Namespaces: Process-Level Separation

Namespaces provide the foundation of container isolation:

  • PID namespace: Containers can’t see host processes
  • Network namespace: Separate network stack per container
  • Mount namespace: Isolated filesystem view
  • User namespace: Map container users to host users (often disabled)
  • UTS namespace: Separate hostname and domain
  • IPC namespace: Isolated inter-process communication

The Problem: Namespaces provide process isolation, not security isolation. A compromised container process still runs on the host kernel with potential access to kernel vulnerabilities.

Control Groups (cgroups): Resource Limiting

Cgroups limit resource consumption but don’t prevent security breaches. They can prevent denial-of-service attacks but won’t stop privilege escalation or data exfiltration.

Capabilities: Granular Privilege Control

Linux capabilities break down root privileges into specific permissions. However:

  • Default container configurations often retain dangerous capabilities
  • Many applications require capabilities that can be exploited
  • Capability bypass vulnerabilities exist in the kernel

Seccomp: System Call Filtering

Seccomp profiles filter which system calls containers can make. Issues include:

  • Default profiles are often permissive for compatibility
  • Kubernetes disables seccomp by default in many configurations
  • Applications may require dangerous system calls for legitimate functionality

Common Security Mistakes in Container Environments

Running as Root

The Problem: Most container images run processes as root (UID 0), providing full privileges within the container namespace.

Why It’s Dangerous: If an attacker escapes the container, they potentially gain root access on the host.

The Fix:

# Create a non-root user
RUN useradd -r -u 1001 appuser
USER appuser

Mounting the Docker Socket

The Problem: Mounting /var/run/docker.sock into containers for “Docker-in-Docker” functionality.

Why It’s Dangerous: Equivalent to giving the container root access to the host system.

Example:

# NEVER DO THIS
docker run -v /var/run/docker.sock:/var/run/docker.sock myapp

Privileged Containers

The Problem: Using --privileged flag removes most security restrictions.

Why It’s Dangerous: Privileged containers can access host devices, load kernel modules, and bypass most isolation mechanisms.

Overprivileged Capabilities

The Problem: Adding unnecessary Linux capabilities or running with default capability sets.

Example of Dangerous Capabilities:

  • CAP_SYS_ADMIN: Nearly equivalent to root
  • CAP_NET_ADMIN: Network configuration control
  • CAP_SYS_MODULE: Kernel module loading

Host Network and PID Sharing

The Problem: Using --network host or --pid host breaks container isolation.

Why It’s Dangerous: Containers gain direct access to host networking or process space.

Kubernetes: Amplifying Container Security Challenges

Kubernetes environments face additional complexity that amplifies container security risks:

Default Configurations Favor Convenience

Kubernetes often prioritizes ease of deployment over security:

  • Seccomp disabled by default in many configurations
  • Permissive network policies
  • Default service accounts with unnecessary permissions
  • No pod security standards enforcement

Shared Kernel Vulnerabilities

In Kubernetes clusters, a kernel vulnerability on any node potentially affects all containers on that node. Unlike VMs with separate kernels, containers share this attack surface.

Network Complexity

Kubernetes networking introduces additional attack vectors:

  • Pod-to-pod communication often unrestricted by default
  • Service mesh complexity can introduce vulnerabilities
  • Network policies frequently misconfigured or absent

Orchestration Attack Surface

The Kubernetes control plane itself becomes an attack target:

  • etcd access equivalent to cluster-admin privileges
  • API server vulnerabilities affect entire clusters
  • kubelet access can compromise individual nodes

The Linux Kernel Reality Check

The fundamental issue with container security is that containers run directly on the host Linux kernel. This creates several security implications:

Shared Kernel Attack Surface

All containers on a host share the same kernel. A kernel vulnerability exploitable from within a container affects the entire host and all other containers.

System Call Interface

Containers make system calls directly to the host kernel. Even with seccomp filtering, the attack surface remains significant.

File System Access

Despite mount namespaces, containers can potentially access host filesystem through:

  • Volume mounts (especially with wrong permissions)
  • Symlink attacks
  • File descriptor passing
  • Kernel bugs in filesystem handling

Device Access

Containers can potentially access host devices through:

  • Device node mounting
  • Direct hardware access in privileged mode
  • Kernel module loading capabilities

Building Truly Secure Container Environments

Defense in Depth Strategy

Security should never rely on containers alone. Implement multiple layers:

1. Secure Container Images

# Use minimal base images
FROM scratch
# Or use distroless images
FROM gcr.io/distroless/java:11

# Run as non-root user
USER 65534:65534

# Read-only root filesystem
# (Configure in Kubernetes with readOnlyRootFilesystem: true)

2. Kubernetes Security Contexts

apiVersion: v1
kind: Pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 65534
    fsGroup: 65534
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      capabilities:
        drop:
        - ALL
      seccompProfile:
        type: RuntimeDefault

3. Network Policies

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

4. Pod Security Standards

apiVersion: v1
kind: Namespace
metadata:
  name: secure-namespace
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Runtime Security Solutions

Consider additional runtime security tools:

Container Runtime Security:

  • gVisor: Provides application kernel in userspace
  • Kata Containers: VM-based container isolation
  • Firecracker: Microvm-based isolation

Runtime Monitoring:

  • Falco: Runtime security monitoring using eBPF
  • Tracee: Behavioral monitoring and threat detection
  • Sysdig: Container runtime security platform

Host Hardening

Don’t forget the underlying infrastructure:

Operating System Hardening:

  • Minimal OS installations (Container-optimized distributions)
  • Regular security updates
  • Kernel hardening (grsecurity, KSPP)
  • File system permissions and access controls

Node Security:

  • Disable unnecessary services
  • Implement proper logging and monitoring
  • Use immutable infrastructure patterns
  • Regular vulnerability scanning

Lessons from CVE-2025-9074 for Production Environments

Assume Breach Mentality

Design systems assuming containers will be compromised:

  • Implement comprehensive monitoring
  • Limit blast radius through network segmentation
  • Use least-privilege access controls
  • Plan incident response procedures

Zero Trust Networking

Don’t trust container-to-container communication by default:

  • Implement mutual TLS for service communication
  • Use network policies to restrict traffic
  • Monitor and log all network activity
  • Implement service mesh for traffic encryption and control

Regular Security Assessments

Continuously evaluate container security:

  • Regular vulnerability scanning of images and runtime
  • Penetration testing of container environments
  • Security configuration audits
  • Threat modeling for containerized applications

Security Training and Awareness

Educate development and operations teams:

  • Container security fundamentals
  • Secure development practices for containerized applications
  • Incident response procedures
  • Regular security updates and threat briefings

The Path Forward: Embracing Security Reality

CVE-2025-9074 and similar vulnerabilities will continue to emerge as long as the industry treats containers as security boundaries. The path forward requires acknowledging several realities:

Containers Are an Operational Tool, Not a Security Tool

Containers excel at packaging, distribution, and orchestration. Security must be implemented through additional layers and practices.

Security Must Be Designed In, Not Bolted On

Security considerations should influence architecture decisions from the beginning, not be added as an afterthought.

Defense in Depth Is Non-Negotiable

No single security mechanism is sufficient. Implement multiple overlapping security controls.

Continuous Learning and Adaptation

Container security is an evolving field. Stay informed about new vulnerabilities, attack techniques, and defensive strategies.

Conclusion: Breaking Free from the Isolation Illusion

CVE-2025-9074 serves as a critical reminder that the perception of container security often exceeds the reality. The vulnerability demonstrated how easily the “secure by default” assumption can be shattered with a few lines of code.

The lesson is clear: containers provide process isolation and resource management, not security boundaries. Treating them as security tools without implementing proper additional controls is a recipe for compromise.

Security in containerized environments requires understanding the underlying Linux kernel, implementing defense in depth, and maintaining vigilance about new attack vectors. Only by breaking free from the isolation illusion can we build truly secure container infrastructures.

The next time someone tells you “it’s secure because it’s in a container,” remember CVE-2025-9074 and the three lines of Python that could compromise an entire host system. Container security starts with acknowledging that containers, by themselves, are not secure—and building robust security controls from that foundation.

Remember: In the world of containers, isolation is an operational feature, not a security guarantee. Plan accordingly.