The Scale of the Problem

OpenClaw has grown from a niche project to one of the most popular open-source AI assistant frameworks. That growth comes with a security surface that most users do not think about.

A Shodan scan reveals over 220,000 OpenClaw instances with exposed ports. Many run default configurations with no authentication, no TLS, and no network isolation. These instances hold WhatsApp session tokens, API keys for LLM providers, and often personal conversation history.

Shared Infrastructure Means Shared Risk

Most managed OpenClaw platforms use container-based hosting. Your instance runs as a Docker container or Kubernetes pod alongside other users. This is efficient. It is also a problem.

Containers share the host operating system kernel. A kernel exploit in one container can affect every container on the same host. This is not theoretical — it happens regularly. When your AI agent has access to your WhatsApp account and API keys, a shared kernel is a shared liability.

Container Isolation vs VM Isolation

The difference matters. Here is a simplified view:

Containers (Docker, Kubernetes)

  • Share the host kernel with every other container
  • Isolation comes from Linux namespaces and cgroups — software boundaries
  • A kernel vulnerability breaks the isolation for all tenants
  • Fast to start, efficient with resources

MicroVMs (Firecracker)

  • Each instance gets its own dedicated Linux kernel
  • Isolation enforced by hardware virtualization (KVM) — the CPU itself
  • A kernel vulnerability in one VM cannot affect another
  • Nearly as fast as containers thanks to snapshot restore

CVE-2026-25253: A Real-World Example

In early 2026, CVE-2026-25253 disclosed a remote code execution vulnerability in OpenClaw's message processing pipeline. An attacker could craft a message that executed arbitrary code on the host — a 1-click RCE that required nothing more than sending a WhatsApp message.

This affected an estimated 40,000 instances running vulnerable versions. On shared container platforms, a single exploited instance could pivot to neighboring containers through the shared kernel. On VM-isolated infrastructure, the blast radius was limited to a single user's sandbox.

Why Firecracker MicroVMs Are Different

Firecracker is the virtualization technology built by Amazon for AWS Lambda and Fargate. It was purpose-built for multi-tenant workloads where isolation cannot be optional.

  • Minimal attack surface — Firecracker implements fewer than 30 device emulations, compared to hundreds in QEMU. Less code means fewer vulnerabilities.
  • Hardware-enforced boundaries — Uses KVM (kernel-based virtual machine) for isolation. The CPU enforces the boundary, not software.
  • Snapshot restore — MicroVMs resume from a pre-booted memory image instead of cold-booting, so better isolation does not mean slow starts.
  • Jailer process — Each Firecracker process runs in its own chroot, cgroup, and namespace. Defense in depth beyond the VM boundary.

What OmniClaw Does Differently

OmniClaw runs every OpenClaw instance in its own Firecracker microVM. Here is what that means in practice:

  • Per-user VM — Your agent has its own kernel, its own filesystem, its own network stack. No other user's code runs on your kernel.
  • Encrypted credential vault — API keys are stored encrypted (AES-256-GCM) in a per-account vault outside the sandbox. When a sandbox requests them, the gateway decrypts them and writes them into that sandbox as an environment file. Injection writes every stored key, so if the sandbox is compromised, all of those keys are exposed. Store only the keys your agent needs.
  • Network isolation — Each VM runs in its own network namespace with its own virtual interface, and traffic between VMs is blocked. Your agent cannot reach other agents. Other agents cannot reach yours.
  • Auto-destroy — Idle VMs are destroyed after a configurable period. No persistent attack surface for unused instances.

The Credential Storage Problem

Most OpenClaw deployments store credentials in one of two ways:

  • Plaintext on the filesystem — The default for self-hosted setups. API keys sit in .env files or config directories. Anyone with filesystem access has your keys.
  • Environment variables — Better than files, but still visible to any process inside the container. On shared platforms, container escape means credential theft.

OmniClaw takes a different approach: vault injection. Credentials are stored encrypted (AES-256-GCM) in a per-account vault outside the VM, and the API only returns key names. When a sandbox requests them, the gateway decrypts them and writes them into that sandbox as an environment file. An attacker with code execution inside your sandbox can read every key written into it, and vault injection writes all of your stored keys, so store only the keys your agent needs. Read more about our approach on the security page.

Further Reading