Replit's microVM sandbox avoided 96% of recent Linux kernel CVEs

Felix Laurent 6 Nov 2026 4 min read

AI agents

Replit has rebuilt the sandbox engine that runs its users' code and AI agents. Each sandbox now runs in its own microVM with its own minimal Linux kernel, instead of a Docker container that shares the host kernel. Replit described the design in an engineering post on November 4, 2026, and says the rollout is already finished.

CEO Amjad Masad summed up the main claim on X: Replit's custom kernel avoids 96% of the Linux vulnerabilities disclosed lately. The number is real, but it measures something narrower than "zero-days," as the post itself shows.

Why Replit left containers

Replit used to run code in Docker containers on Google Compute Engine VMs. Containers share the host's kernel, so a kernel bug reachable from inside one can let an attacker escape. According to Replit, an escape could reach other workloads, credentials or network endpoints on the host.

Two more reasons pushed the rewrite. Users wanted to run Docker inside their sandboxes, which needs privileges Replit could not safely grant on a shared kernel. Replit also wanted to run sandboxes in customers' own AWS, Google Cloud and Azure accounts. The team rebuilt the engine from scratch and started using it internally in February 2026.

AI agents made the problem sharper. Replit's post points to OpenAI's Hugging Face incident, when agents in a security evaluation escaped their isolation. For Replit, it proved that autonomous agents can reach real systems beyond their scope.

How the microVM sandbox works

Each sandbox runs as a lightweight virtual machine under Cloud Hypervisor, a virtual machine monitor that shares components with AWS's Firecracker. Replit picked it for features such as device hotplug, memory snapshots and live migration. The monitor itself runs as an unprivileged process with no Linux capabilities.

Getting a sandbox takes about 500 milliseconds, according to Replit. That includes attaching and mounting the user's disk, which comes from remote block storage on demand. Warm pools of ready VMs and parallel setup keep it fast. Replit says one storage component, a virtio-blk backend, was "one of our first completely AI-written components," built with Claude Sonnet 4.

Speed was the easy part. The bigger change sits inside each VM.

The custom kernel and the 96% claim

Replit builds the guest kernel from tinyconfig, Linux's smallest configuration, and adds only what sandboxes need. Bluetooth, wireless, USB and display drivers are left out. Drivers are built in, and module loading is disabled once the guest starts. Automated agents update the build daily.

To test the approach, Replit audited 6,211 Linux kernel CVEs published by the Linux CNA from June 1 to November 4, 2026. It says it avoided 5,969 of them, or 96.1%. Its kernel already had the fix before disclosure for 4,375 of them. Another 676 hit code its configuration leaves out.

Bar chart of 6,211 Linux kernel CVEs, June 1 to November 4, 2026: Replit avoided 96.1%, 70.4% fixed before disclosure, 10.9% excluded by config — How Replit's guest kernel handled Linux kernel CVEs published from June 1 to November 4, 2026, as reported by Replit

Replit does not break down the remaining 918 avoided CVEs. By our arithmetic they were covered by upstream fixes after disclosure. That leaves 242 CVEs, about 4%, that the kernel did not avoid. Replit says at least 15 of the avoided bugs could enable local privilege escalation.

Its sharpest example is CVE-2026-98432, a Linux TCP flaw that Anthropic showed could give a remote attacker root. Replit says it shipped the fix on October 12, more than two weeks before Anthropic described its exploit.

Two caveats apply. The data covers published CVEs over five months, so "zero-days" in Masad's post is loose wording. The figures also come from Replit alone, with no outside audit.

The kernel is only one layer. Replit also moved most network and credential controls outside the VM.

Network and credential controls outside the guest

Each sandbox gets its own network namespace and routing table on the host. Firewall rules block access to cloud metadata and infrastructure addresses. When an egress policy is on, a host-side proxy checks the hostname in each TLS handshake without decrypting traffic and filters DNS. Bandwidth limits sit in the virtual network card. Code inside the guest cannot switch any of this off.

Credentials follow the same idea. For connectors such as GitHub or Google Docs, a credential broker on the host adds the real token after the request is authorized. The workload never receives a reusable API key. Package installs from npm and pip go through a registry firewall that blocks known malicious packages, and Replit's agent swaps blocked dependencies for safe ones.

Monitoring runs on both sides of the VM. eBPF watches processes, files and network activity, and Replit says updates reach production sandboxes within 15 minutes of merging.

Replit's sandbox in a crowded market

Replit is not alone. Its post names Daytona, E2B, Runloop and Blaxel, which raised $59.3 million between them in early 2026. It also cites sandbox work at DeepSeek, Google and the Kubernetes project. Agent platforms now compete on isolation as much as on models.

Replit says hundreds of millions of projects moved to the new engine without data loss or downtime. Part 2 will cover how it runs tens of thousands of microVMs on Kubernetes, and a later post will cover its automated security research.

Is Replit's microVM sandbox safer for AI agents

Yes, on the evidence Replit gives. A separate kernel per sandbox removes the shared-kernel escape path that containers leave open. Moving network and credential controls to the host means a compromised guest still cannot open new routes or steal tokens. That design matters more as agents run code nobody reads first.

The 96% figure needs its context, though. It shows fast patching and a small kernel, measured by Replit on five months of published CVEs. It does not show protection from unknown bugs. The real test is the 242 CVEs left over and the next kernel flaw that lands before a fix does.