firecracker-microvm

Firecracker vs gVisor vs containers: isolation for AI code sandboxes --- title: "Firecracker vs gVisor vs containers: isolation for AI code sandboxes" published: true description: "Containers, gVisor, Firecracker microVMs or full VMs for AI-generated code: isolation, attack surface, start time, memory and compatibility, with measurements." tags: security, ai, linux, devops series: Building OpenDsec canonical_url: kernflux.github.io cover_image: kernflux.github.io --- AI agents write code and run it, and reinforcement learning rollouts run model-written commands by the thousand. That code is untrusted: it may run as root, try to escape, scan the network or exhaust resources. So the first question for the sandbox that runs it is: what isolates it? The short version: - For untrusted code, use microVMs (Firecracker, for example). Each sandbox has its own kernel, and what it can attack is a handful of virtual devices rather than every system call of the host kernel. The cost: you need KVM, and every VM carries a guest kernel and its memory. - Without KVM (an ordinary cloud VM without nested virtualization) but wanting more than a container, use gVisor. It implements a Linux-compatible kernel in user space and needs no hardware virtualization. The cost: compatibility, and performance for system-call-heavy work. - For trusted code, GPUs, or the highest density, use containers. Fastest and leanest, but they share the host kernel, so a kernel bug can mean an escape. - For a full operating system or PCI passthrough, use a QEMU full VM. The rest explains how each works and what it trades, with measurements from our open-source project OpenDsec. At a glance | | Containers | gVisor | Firecracker microVM | QEMU full VM | |---|---|---|---|---| | Kernel | Shared with the host | A user-space "application kernel" (the Sentry, written in Go) handles system calls | Its own Linux kernel per VM, on KVM hardware virtualization | Its own kernel, a full device model | | What code in the sandbox talks to | The host kernel's system calls (narrowed by seccomp) | The Sentry, which does not pass system calls through to the host kernel | A few virtual devices (network, block, vsock and so on) and KVM | More virtual devices | | Needs /dev/kvm | No | No (the default systrap platform); with KVM, the faster KVM platform | Yes | Yes | | Compatibility | Native | Not every system call or /proc and /sys file is implemented | Full Linux | A full system, other operating systems included | | Performance cost | Almost none | System-call-heavy work can be much slower | Compute over 95% of bare metal (official specification) | Slower start, more memory | | License | — | Apache-2.0 | Apache-2.0 | GPL-2.0 | What this post says about gVisor and Firecracker comes from their official documentation, linked at the end. Containers: a shared kernel, a narrowed interface A container combines Linux kernel features: namespaces isolate the view (processes, network, mounts), cgroups limit resources, overlayfs provides the file system. Processes in the sandbox call the host kernel directly, so: - Fast and lean: no virtualization layer; starting one is starting a process, and memory is just what the processes use. - Security depends on how narrow the kernel interface is: drop unneeded capabilities, and refuse dangerous system calls with seccomp (mounts, bpf, userfaultfd, kernel modules, creating user namespaces...). The hundreds of system calls left still reach the host kernel, and one exploitable kernel bug can be an escape. So containers suit trusted code: building images, your own grading programs, GPU training jobs. gVisor: another kernel, in user space gVisor keeps the sandbox away from the host kernel. Its core, the Sentry, is an "application kernel" written in Go that implements Linux's system call interface: a system call from the sandbox is intercepted by the platform layer (by default systrap, built on seccomp) and handled by the Sentry. File access goes through another host process, the Gofer. - Upside: no hardware virtualization needed, so ordinary cloud VMs work; it ships as the OCI runtime runsc, usable from Docker and Kubernetes; a flexible footprint with no fixed VM cost. - Cost: the documentation says gVisor "does not presently implement every system call, /proc file, or /sys file", and system-call-heavy workloads may perform poorly. Agent code can run anything (compilers, package managers, databases), so test compatibility with real workloads. The hosted service Modal uses gVisor for its sandboxes by default. Firecracker microVMs: a minimal VM per sandbox Firecracker is the virtual machine monitor (VMM) AWS built for Lambda and Fargate; it is open source under Apache-2.0. It runs real VMs on KVM but leaves out almost every device, keeping a few: network, block, vsock, entropy, pmem. Its specification: - ≤125 ms from the start request to the guest kernel running; - ≤5 MiB memory overhead for the VMM threads (a 1 vCPU, 128 MiB VM); - compute performance over 95% of bare metal. Root in the sandbox is root of the guest kernel only; escaping means breaking Firecracker's few virtual devices or KVM. In production, Firecracker's own jailer starts it: chroot, cgroups and namespaces, then dropped privileges, plus per-thread seccomp filters. The costs: KVM is required (bare metal, or a cloud VM with nested virtualization); each VM carries a guest kernel and its memory; there is no GPU passthrough. Besides isolation, microVMs do something containers find hard: memory snapshots. A whole VM's memory is saved and restored tens of milliseconds later, with running processes carrying on. That is what makes starting from a snapshot, pause and resume, and forking with memory possible. E2B is built on Firecracker too. QEMU full VMs QEMU has a full device model: it can run an image's own init, other operating systems, and pass a GPU through to the VM over PCI. The costs are a slower start, more memory and a larger attack surface. Use it when the task needs a full system, not as the default for many sandboxes. Measured: OpenDsec's three backends OpenDsec has container, Firecracker microVM and QEMU full VM backends (not gVisor), and the caller picks one when creating a sandbox. Measured on the project's bare-metal test machines (2 × AMD EPYC 9Y24, 384 threads, 1.5 TB RAM): | | Container | Firecracker microVM | QEMU full VM | |---|---|---|---| | Start | about 0.1 s | about 0.1 s cold; about 55 ms from a memory snapshot | about 0.23 s | | One create through the API (network and TLS included) | about 65 ms | about 190 ms | about 300 ms | | Pause | Processes frozen; memory can be swapped out | Memory snapshot, then the process ends and all memory is freed; resume about 50 ms | vCPUs stopped, memory kept | | Fork | Files only | With memory | Not supported | | Burst creation | 8,192 (0.25 core, 256 MB) on two nodes, all succeeded | 5,120 (512 MB) on one node, all succeeded | — | The 5,120 microVMs deserve a word: they requested 2.6 TB of memory in total, and the host actually used about 468 GB, about 91 MB per VM. Two things do that: - Free page reporting: the guest kernel tells the host which pages are free, and the host takes them back. - virtio-pmem with DAX: read-only images are mapped into VMs through a pmem device, so the page cache of an image is shared by every VM using it instead of cached once per VM. So the "every VM has its own guest memory" cost can be kept small under real load. Why OpenDsec defaults to microVMs DeepSeek's DSec paper uses containers as its main backend and microVMs where stronger isolation is needed. OpenDsec made Firecracker microVMs the default instead (the paper, explained), because of: 1. Isolation: agent code is untrusted, and not sharing the host kernel is the most direct defence. 2. Memory snapshots: prepare an environment once, snapshot it, and start each sandbox from the snapshot, with dependencies, loaded models and running services in place, ready in about 55 ms. 3. Fork: copy a running sandbox with its memory, for tree search and fanning many rollouts out of one state. 4. Enough density: as measured above, microVM memory overhead can be brought down to about 91 MB each under real load. The container backend stays, for GPU work (Firecracker has no GPU passthrough), for large batches of trusted work most sensitive to start time and memory, and for machines without KVM. Whatever the backend, OpenDsec adds the same layers on the host: outbound network denied by default (nftables and a DNS proxy), CPU core scheduling (two sandboxes never run on the two hyperthreads of one physical core at once, which blocks side channels through hyperthreading), and a cap on each command's output; the agent and the grader can also run as different users. See the security model. How to choose | Your situation | Use | |---|---| | Untrusted, AI-generated code, with bare metal or nested virtualization | Firecracker microVMs | | Untrusted code, but only ordinary cloud VMs without KVM | gVisor (test your workload's compatibility and speed first) | | Already on Kubernetes and want a stronger runtime | gVisor (runsc), or something like Kata Containers that runs containers in VMs | | Trusted code, speed and density first, or GPUs | Containers, with seccomp and a minimal capability set | | A full operating system or PCI passthrough | QEMU full VMs | | Pause and resume, start from a snapshot, fork with memory | microVMs | FAQ Which is more secure, Firecracker or gVisor? Both are stronger than plain containers, by different means. Firecracker uses hardware virtualization, so the sandbox faces a few virtual devices and KVM; gVisor reimplements the kernel interface in user space, so the sandbox faces the Sentry. For untrusted code on machines with KVM we recommend microVMs: the boundary is hardware virtualization, and you get memory snapshots too. Can Docker containers run AI-generated code? Yes, if you accept the risk: a container shares the host kernel, and one exploitable kernel bug can be an escape. At least drop extra capabilities, refuse dangerous system calls with seccomp, forbid creating user namespaces, and restrict the network. Prefer microVMs or gVisor for untrusted code. What does Firecracker need? A Linux host with /dev/kvm: a bare-metal server, or a cloud VM with nested virtualization. Without KVM, use containers or gVisor. Are microVMs much slower than containers? Not to start: OpenDsec measures about 0.1 s for a cold microVM and about 55 ms from a memory snapshot, the same order as a container. For compute, Firecracker's specification is over 95% of bare metal. The difference is memory: each VM has its own guest kernel, which free page reporting and a shared page cache keep small. Does gVisor run every program? Not necessarily. gVisor's documentation says it does not yet implement every system call or /proc and /sys file, and system-call-heavy workloads may perform poorly. Test with your real workload first. Can I use Firecracker on Kubernetes? Through projects such as Kata Containers (Firecracker's README says it has been integrated into Kata Containers). OpenDsec instead manages Firecracker on its nodes itself, without Kubernetes; see concepts. References - Firecracker: README, specification - gVisor: documentation, platforms - OpenDsec: concepts (the backends), security model, compared with E2B, Daytona and Modal What this post says about gVisor and Firecracker comes from their official documentation, checked on 2026-10-25; OpenDsec's numbers come from the project's test records.

Secure and fast microVMs for serverless computing. firecracker-microvm/firecracker

@rauchg @OpenAI firecracker's prod host doc covers smt, ksm and rowhammer but never mentions cache partitioning (intel cat), a knob aimed at your cache eviction channel. the dram one probably gets through even with it github.com/firecracker-microvm/firecracker/blob/m…

AI Agents Are Quietly Being Rewritten in Rust OpenAI, Block, and Perplexity all rebuilt key parts of their AI stack in Rust. In this video I break down why the layer around the model (agents, sandboxes, and tooling) is moving to Rust, and the one catch most people skip. I’m a fresh grad learning Rust and harness engineering in public, so every claim here comes from sources I checked, linked below. Chapters 0:00 Elon’s Larp 00:36 Codex CLI: TypeScript to Rust 01:46 Goose: Python to Rust 02:22 Sandboxes: Firecracker and Perplexity SPACE 03:14 uv, Ruff, and OpenAI buying Astral 03:50 Hugging Face tokenizers and Candle 04:13 The catch 04:45 Advance Sources Elon post : x.com openai/codex block/builderbot perplexityai/SPACE x.com codex#1174 news.ycombinator.com reddit.com codex#1174 news.ycombinator.com reddit.com github.com/aaif-goose/goose/blob/main/crates/goos… goose-docs.ai github.com/aaif-goose/goose/blob/main/crates/goos… firecracker-microvm.github.io x.com anthropics/claude-code reddit.com huggingface.co huggingface/candle astral-sh/uv astral.sh github.com/perplexityai/SPACE/tree/main/crates/ap… firecracker-microvm/firecracker github.com/aaif-goose/goose/tree/main Follow along Rust playlist: youtube.com Building Harness playlist: youtube.com Portfolio: vkgeed.in X post for this video: x.com #rust #aiengineering #softwareengineering

Is a Docker Container a Sandbox? AI Agent Sandboxing Explained: seccomp, gVisor, Firecracker, Kata and Wasm {% embed youtu.be %} When headlines say an AI agent "escaped its sandbox"... what wall did it pass? Some sandboxes are walls. Some are just curtains. Containers, seccomp, gVisor, Firecracker, Kata, WebAssembly, V8 isolates. They all sort into one ladder, with one question: How much of the host kernel can the code reach? And there's one door none of them close. We'll get there.  Why sandbox at all? Your agent writes code, then runs it. But who really wrote it? Treat agent code like code from a stranger. Because it might be. The building and its plumbing: the kernel Here's the building. Every program lives in its own apartment. Down in the basement is the kernel: the plumbing every apartment shares. Open a file, send a packet? You ask the kernel. That request is a syscall. Linux has hundreds of them, and every one is a pipe into the basement. One bug in that plumbing, and a tenant can flood the whole building. !Hundreds of syscalls running from every apartment into one shared kernel; one bug floods the whole building Containers: a locked room So what's a container? A locked room in this same building. - Namespaces control what you can see: your own processes, files and network. - cgroups control how much you can use: CPU, memory, how many processes. On a Mac or Windows, Docker runs a Linux VM, so the shared kernel is that VM's. seccomp: the list of taps Next layer: seccomp, a list of taps you're allowed to turn. It's a tiny filter program that checks each syscall's number and arguments, and answers allow, errno or kill: read allow write allow mount blocked ptrace blocked kexec_load blocked openat allow But the kernel's own docs say it plainly: syscall filtering isn't a sandbox. Is a Docker container a sandbox? Not on its own. In January 2024, a bug in runc, the tool that starts containers, let them reach the host's files. That's CVE-2024-21626. A full container escape. And that wasn't even the kernel. The classic own-goal: docker.sock Mounting the Docker socket into the container: docker run -v /var/run/docker.sock:/var/run/docker.sock agent Whoever controls that socket controls the Docker daemon, and the daemon runs as root. Volumes only, a separate network? Better. But it's still the same kernel. So the people saying "if it escaped, it wasn't a sandbox"? They're right. If it shares a kernel, it's a curtain, not a wall. gVisor: hire a concierge So how do you keep code away from the pipes? Hire a concierge. That's gVisor: its Sentry is a kernel, written in Go, running in user space. Your code makes a syscall, and the Sentry answers it itself. It only makes a small, filtered set of host calls. Files go through a helper, the Gofer. !gVisor: your code's open() goes to the Sentry in user space instead of the host kernel; files go through the Gofer What does the concierge cost? Every syscall takes a detour, so syscall-heavy work slows down. And some programs expect plumbing the Sentry doesn't provide, so compatibility drops. MicroVMs: your own tiny house Still nervous about sharing a building? Then move out. Get your own tiny house. A microVM runs your code on its own guest kernel, with its own plumbing. Firecracker is the VMM, the virtual machine monitor, built on KVM, the hypervisor inside Linux. The house still has one metered service line into the building's basement: KVM. To escape, code has to get past its own kernel, and then break the VMM or KVM too. Share a folder in, though, and you've cut a door in that wall. ![Firecracker microVM: your code on its own guest kernel, with only the VMM and KVM between it and the host kernel] (dev-to-uploads.s3.us-east-2.amazonaws.com) Isn't a VM slow? Firecracker's spec says the guest reaches init within 125 ms: [0.000] InstanceStart [0.003] guest kernel boots... [0.125] /sbin/init /dev/kvm: required And the VMM itself adds at most about 5 MB of memory. Low-powered machine? The overhead is tiny, if it has KVM. The guest's own memory is the real bill. Many sandboxes at once? Fine. They only talk to each other if you wire up a network. That's why platforms like E2B describe a sandbox as a Linux VM made on demand. Even Docker's own agent product, Docker Sandboxes, runs each agent in its own microVM. Kata Containers: a container's front door But your tools speak containers, not VMs. So Kata puts a lightweight VM behind the container interface. Same front door as an apartment, but a tiny house behind it. Your container tools never know they're running a VM. WebAssembly and V8 isolates: the glovebox Now flip it. Picture a sealed glovebox in the lobby. You work through the gloves you're handed, and nothing else. A WebAssembly module's memory is bounds-checked. Step outside it, and the module traps: no pipes to the basement at all. Same idea for JavaScript. V8 is Chrome's JavaScript engine, and an isolate is one sealed instance of it. It gets its own memory and only the APIs it's handed. Cloudflare Workers run thousands per process. Cloudflare says they start about a hundred times faster than a containerized Node process, using a tenth of the memory. The glovebox catch So the glovebox is the strongest rung, right? Not so fast. Now the wall is the runtime itself, and runtimes have bugs. Break one, and you're a normal host process. In 2024, V8's team said even its newest sandbox wasn't yet a strong boundary. Side channels, timing the shared CPU, still work too. Even between tiny houses. The ladder Sorted by how much host kernel the code can reach: | Rung | Analogy | What the code reaches | |---|---|---| | Container + seccomp | locked room, list of taps | the shared kernel, filtered by seccomp | | gVisor | the concierge | the Sentry, which makes a small, filtered set of host calls | | Firecracker microVM / Kata | your own tiny house | only its VMM and the KVM under it | | Wasm / V8 isolates | the glovebox | nothing but their imports | !The sandbox ladder: rungs from container to V8 isolate, with what each reaches of the host kernel and what it costs And every wall here is software, so any rung can have bugs. Which rung should you pick? - Your own agent on your own repo? A container-level sandbox is the floor. An injected command's easy win is your network, not a kernel exploit, and the next rule shuts that. - Running strangers' code, or anything multi-tenant? Give it its own kernel: gVisor or a microVM. The door no rung closes: the network So what if your agent sat in a perfect microVM, holding real API keys, with open internet? Without network isolation, one injected instruction and one outbound request, and your keys are gone. Every wall held. The code just walked out the front door. Egress: the mailroom Allowlist destinations: a mailroom that only delivers to addresses on the list. ALLOWLIST pypi.org github.com everything else: DENIED Can it still leak? If it reads your data and can reach an allowed host, yes. So keep that list as short as the job allows, and lock down DNS too. Secrets: keep the master keys out of the house The sandbox gets a placeholder, and the mailroom attaches the real credential on the way out: inside the sandbox: Authorization: Bearer PLACEHOLDER after the mailroom: Authorization: Bearer sk-live-... Injected code can read that placeholder all day. Off the box, it's worthless. It can still use the key through the mailroom, so keep the allowlist short. !Keys stay out: the agent only holds a placeholder; the mailroom injects the real key at egress Agent code is untrusted on your laptop too: review it, or run it sandboxed. A real example: Claude Code's sandbox Does anyone build it this way? Here's one example: Claude Code's sandbox. It's off by default. You turn it on with: /sandbox On Linux it uses bubblewrap, the same namespaces trick a container uses. On macOS, Seatbelt, Apple's built-in sandbox. Commands get no direct route out. A host proxy checks every domain against an allowlist that starts empty. Set up masking, and the proxy swaps a placeholder key for the real one. Its own docs say it reduces risk, but isn't a complete isolation boundary. For strangers' code, climb. Recap One building. The kernel is the shared plumbing. A container is a locked room. seccomp is the list of taps. gVisor is the concierge. A microVM is your own tiny house, and Kata gives it a container's front door. Wasm and isolates are the glovebox. And the mailroom guards the one door no wall closes. So did that agent escape its sandbox? Ask two things: was it a wall, or a curtain? And which door was open? Which rung is your agent on right now? Tell me in the comments. More in this series: AI agent identity with SPIFFE and SPIRE, Pi 1.0 and Pi Durable, AI reverse engineering. --- This is the written version of a 10-minute animated explainer on RuntimeStack. Sources: syscalls(2), namespaces(7), cgroups(7), seccomp BPF, Red Hat RHSB-2024-001, CVE-2024-21626, Dirty Pipe, Docker Engine security, Docker Sandboxes architecture, Docker Desktop VMM, gVisor docs, gVisor platforms, Firecracker README, Firecracker specification, Firecracker getting started, Firecracker (NSDI '20), Kata Containers, Kata hypervisors, WebAssembly security, How Workers works, Workers security model, The V8 Sandbox, Claude Code sandboxing, E2B docs, OWASP LLM01.

Firecracker MicroVMs: Run Untrusted Code Like Lambda Does, Then Snapshot It Your AI agent just wrote a script. It looks reasonable. Now what? Run it on your laptop? In a container that shares your host kernel? Or wait 30 seconds for a full VM to boot? AWS Lambda faced this exact problem at enormous scale: run millions of untrusted functions, keep them isolated from each other, start them fast. Their answer is Firecracker, an open-source microVM manager built on KVM. It boots a hardware-isolated virtual machine in about 125 milliseconds with under 5 MiB of memory overhead. It powers Lambda and Fargate, and Netlify recently migrated their edge functions to it, reporting roughly 2 ms p99 cold-start latency. In this tutorial you will boot a Firecracker microVM, run an untrusted script inside it, snapshot the running VM, and restore it in a brand-new Firecracker process. Snapshot and restore is the killer feature here. It is the same mechanism behind Lambda SnapStart: boot once, snapshot at the ready state, restore in about a second whenever work arrives. The full code for this tutorial, every config and script, lives in the accompanying repo: oukhay/draft-dev-samples. Prerequisites - A host with KVM access: a physical machine with virtualization enabled in the BIOS, or an EC2 virtual instance with nested virtualization turned on (for example c8i.xlarge with --cpu-options "NestedVirtualization=enabled"; supported on the c8i, m8i and r8i families, off by default, enable at launch). Bare metal (for example i3.metal) still works but is only a fallback now. Check with: [ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "KVM OK" || echo "KVM MISSING" It will not work on a regular virtualized EC2 instance with nested virtualization off, or on a laptop without KVM. See KVM-TEST-RUN.md for the full host options and costs. - Firecracker v1.17.0 (latest at the time of writing), curl, wget, iproute2, iptables, ssh, plus squashfs-tools and e2fsprogs (Step 1 builds the root filesystem with unsquashfs and mkfs.ext4). Step 1: Download Firecracker, a kernel, and a root filesystem ARCH=$(uname -m) FC_VERSION=v1.17.0 S3="https://s3.amazonaws.com/spec.ccfc.min" # Firecracker binary (the binary inside the tarball carries a version suffix) curl -L -o firecracker.tgz \ https://github.com/firecracker-microvm/firecracker/releases/download/${FC_VERSION}/firecracker-${FC_VERSION}-${ARCH}.tgz tar -xzf firecracker.tgz sudo install -m 755 release-${FC_VERSION}-${ARCH}/firecracker-${FC_VERSION}-${ARCH} \ /usr/local/bin/firecracker # The kernel and root filesystem come from the Firecracker CI artifacts, the # same source the official getting-started guide uses. Find the latest build: CI_ARTIFACTS_PREFIX=$(curl -fsSL "$S3?list-type=2&prefix=firecracker-ci/&delimiter=/" \ | grep -oP "(?<=<Prefix>)firecracker-ci/[0-9]{8}-[^/]+/(?=</Prefix>)" | sort | tail -1) # Kernel: grab the newest vmlinux-* and save it as ./vmlinux latest_kernel_key=$(curl -fsSL "$S3?list-type=2&prefix=${CI_ARTIFACTS_PREFIX}${ARCH}/vmlinux-" \ | grep -oP "(?<=<Key>)(${CI_ARTIFACTS_PREFIX}${ARCH}/vmlinux-[0-9]+\.[0-9]+\.[0-9]{1,3})(?=</Key>)" \ | sort -V | tail -1) wget "$S3/${latest_kernel_key}" -O vmlinux # Root filesystem: the CI image is a squashfs with no SSH key baked in, so # generate one, patch the public key into the image, and build an ext4 from it latest_ubuntu_key=$(curl -fsSL "$S3?list-type=2&prefix=${CI_ARTIFACTS_PREFIX}${ARCH}/ubuntu-" \ | grep -oP "(?<=<Key>)(${CI_ARTIFACTS_PREFIX}${ARCH}/ubuntu-[0-9]+\.[0-9]+\.squashfs)(?=</Key>)" \ | sort -V | tail -1) ubuntu_version=$(basename $latest_ubuntu_key .squashfs | grep -oE '[0-9]+\.[0-9]+') wget -O ubuntu-$ubuntu_version.squashfs.upstream "$S3/$latest_ubuntu_key" unsquashfs ubuntu-$ubuntu_version.squashfs.upstream ssh-keygen -f id_rsa -N "" mkdir -p squashfs-root/root/.ssh cp id_rsa.pub squashfs-root/root/.ssh/authorized_keys mv id_rsa ./ubuntu-$ubuntu_version.id_rsa sudo chown -R root:root squashfs-root truncate -s 1G ubuntu-$ubuntu_version.ext4 sudo mkfs.ext4 -d squashfs-root -F ubuntu-$ubuntu_version.ext4 chmod 400 ./ubuntu-$ubuntu_version.id_rsa Two traps this step avoids, both verified the hard way. First, the old quickstart kernel still floating around (vmlinux.bin, kernel 4.14) boots, but Ubuntu 24.04's systemd warns it is below its 4.15 baseline and the guest's sshd stalls for many minutes waiting on entropy, so every SSH step below looks broken. The CI kernel (6.18 in the verified run) is the matched pair for the CI rootfs and boots to SSH in about a minute. Second, there is no prebuilt ubuntu-24.04.ext4 to download anymore; the squashfs build above is the current official flow. Step 2: Set up host networking The guest gets its IP from its MAC address. We create a tap device on the host and let the guest talk through it: sudo ip tuntap add dev tap0 mode tap sudo ip addr add 172.16.0.1/30 dev tap0 sudo ip link set dev tap0 up sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" HOST_IFACE=$(ip -j route list default | jq -r '.[0].dev') sudo iptables -t nat -A POSTROUTING -o "$HOST_IFACE" -j MASQUERADE Step 3: Boot the microVM through the Firecracker API Firecracker is configured entirely through a REST API on a Unix socket. Start it in one terminal: rm -f /tmp/fc-orig.socket sudo firecracker --api-sock /tmp/fc-orig.socket In a second terminal, configure and boot (the JSON files live in configs/ in the accompanying repo): SOCK=/tmp/fc-orig.socket curl --unix-socket $SOCK -X PUT http://localhost/boot-source \ -H 'Content-Type: application/json' -d @configs/boot-source.json curl --unix-socket $SOCK -X PUT http://localhost/machine-config \ -H 'Content-Type: application/json' -d @configs/machine-config.json curl --unix-socket $SOCK -X PUT http://localhost/drives/rootfs \ -H 'Content-Type: application/json' -d @configs/drive-rootfs.json curl --unix-socket $SOCK -X PUT http://localhost/network-interfaces/net1 \ -H 'Content-Type: application/json' -d @configs/network.json # API calls are async: give the configuration a beat to land sleep 0.5 curl --unix-socket $SOCK -X PUT http://localhost/actions \ -H 'Content-Type: application/json' -d '{"action_type": "InstanceStart"}' sleep 2 ssh -i ./ubuntu-24.04.id_rsa -o StrictHostKeyChecking=no root@172.16.0.2 \ "ip route add default via 172.16.0.1 && echo 'nameserver 8.8.8.8' > /etc/resolv.conf" The configs are small and readable. boot-source.json points at the kernel, machine-config.json asks for 2 vCPUs and 1 GiB of RAM, drive-rootfs.json attaches the Ubuntu image as the root device, and network.json wires the tap device to the guest MAC 06:00:AC:10:00:02, which the guest maps to 172.16.0.2. Step 4: Run the untrusted script guest/untrusted.sh stands in for code an AI agent just generated. We have not audited it. That is the entire point: it executes inside a hardware-isolated microVM, not on our host. ssh -i ./ubuntu-24.04.id_rsa root@172.16.0.2 'bash -s' < guest/untrusted.sh Expected output (abridged): == whoami / hostname == root ubuntu-fc-uvm == init process (should be the guest's, not the host's) == PID 1 systemd == trying to see the host (should fail) == ls: cannot access '/host': No such file or directory == kernel cmdline (microVM kernel) == console=ttyS0 reboot=k panic=1 == done. The host never saw any of this. == The guest has its own PID 1, its own kernel command line, and no path to the host. A container gives you namespaces and cgroups. This gives you a virtual hardware boundary. Step 5: Snapshot the running microVM Snapshotting is a two-phase dance. First pause the VM, freezing all vCPUs and device emulation: curl --unix-socket $SOCK -X PATCH http://localhost/vm \ -H 'Content-Type: application/json' -d '{"state": "Paused"}' Then create a full snapshot: curl --unix-socket $SOCK -X PUT http://localhost/snapshot/create \ -H 'Content-Type: application/json' -d @configs/snapshot-create.json where snapshot-create.json is: { "snapshot_type": "Full", "snapshot_path": "./snapshot/vm.state", "mem_file_path": "./snapshot/vm.mem" } This produces three artifacts: the state file (device and emulation state), the memory file (a full copy of guest RAM), and your disk files, which Firecracker leaves for you to manage. It drains and fsyncs the block devices during creation, and fsyncs the snapshot files by default, so the result is durable. Step 6: Restore it in a new process, and time it Kill the original Firecracker process. The snapshot is now just files on disk. Start a fresh process on a new socket, then load: rm -f /tmp/fc-restore.socket sudo firecracker --api-sock /tmp/fc-restore.socket & sleep 0.5 time curl --unix-socket /tmp/fc-restore.socket -X PUT http://localhost/snapshot/load \ -H 'Content-Type: application/json' -d @configs/snapshot-load.json with snapshot-load.json: { "snapshot_path": "./snapshot/vm.state", "mem_backend": { "backend_path": "./snapshot/vm.mem", "backend_type": "File" }, "resume_vm": true } Measured on the c8i.xlarge test host (nested virtualization), that time came back at 0.093s real, and Firecracker's own log put the load request at 4.1 ms. The restored guest answered SSH immediately, with its uptime continuing from the original boot, because the guest clock is part of the snapshot. A few things worth noticing: - Load is only allowed before the VM is configured. The only things you may set up beforehand are logging and metrics. - The memory file is memory-mapped (MAP_PRIVATE), so pages load on demand instead of all up front. That is why restore lands in about a second even for larger guests. (There is also a Uffd backend if you want a userspace process to serve page faults.) - resume_vm: true skips the separate resume call. Without it, the loaded VM sits in Paused and you resume it with PATCH /vm {"state": "Resumed"}. - The TAP device and disk files must exist at the same relative paths for the new process. - Treat the memory file as immutable after loading. It backs guest memory through the page cache; modifying it corrupts the guest. Verify the restored guest is alive and identical: ssh -i ./ubuntu-24.04.id_rsa root@172.16.0.2 "uptime; ls /tmp" The pattern: pre-warmed sandboxes for agent code This is the use case that makes the feature matter. Instead of booting a sandbox per task: 1. Boot one template microVM with your toolchain baked into the rootfs. 2. Warm it to the ready state (agent runtime listening, dependencies loaded). 3. Snapshot it. Terminate the original. 4. For every task: load the snapshot in a fresh Firecracker process, hand the task to the agent, destroy the VM when done. Every task gets a pristine, hardware-isolated environment in about a second, and nothing persists between tasks. Boot cost is paid once, amortized over thousands of restores. This is Lambda SnapStart's trick, and it is exactly what Netlify now does at the edge: snapshot when the runtime is listening, scale to zero, restore from the memory-mapped snapshot on the next request. Gotchas worth knowing before production - Vsock resets on snapshot. Open vsock connections close; listen sockets in the guest survive and accept new connections after resume. - Network is not guaranteed across restore. Plan to re-establish connectivity rather than assuming it survives. - Snapshot files are only CRC-checked. Firecracker trusts the host and the files. If snapshots cross a trust boundary, encrypt and authenticate them yourself. - Never resume the same snapshot twice in production. Identifiers, entropy pools, and tokens would be duplicated. If guests must detect restores, expose the VMGenID device. - The guest clock freezes at snapshot time. Update it after restore, or pass clock_realtime: true on load (needs host kernel 5.16+). - Snapshot after the kernel has booted, not during early boot, or the restore may crash. - Diff snapshots are still developer preview. Full snapshots are the stable path. - In production, run Firecracker under the jailer for an extra containment layer. Reality check: your microVM is the security boundary, and boundaries get breached This tutorial treats the Firecracker microVM as a hardware-isolated sandbox for untrusted agent code. In the fall of 2026, security researcher Paulos Yibelo showed that the isolation boundary itself is not bulletproof. Through Vercel's Sandbox bug bounty challenge, he reported a flaw that let code inside a guest VM read host memory, and in his lab, on machines matching Vercel's configuration, he took it all the way to host root. Vercel confirmed the finding and paid the program's maximum $50,000 bounty. CEO Guillermo Rauch announced it on October 3, 2026: "We've confirmed a KVM 0day through our Vercel Sandbox bounty program." Why this matters for you: Vercel Sandbox runs untrusted AI workloads, including AI agent code, inside Firecracker microVMs on bare-metal EC2 hosts, and Vercel identifies the microVM, not the container, as its primary security boundary. The exact boundary this tutorial builds on. Yibelo's finding crosses exactly that line. The technical shape is worth understanding, because the bug was not in KVM at all. It was in the host Linux kernel's IPv4 stack (CVE-2026-99999, CVSS 9.3). A guest can hand the host deferred-checksum metadata (CHECKSUM_PARTIAL, via virtio-net and the TAP device) that the host trusts without validating it properly. When the host completes the checksum and later fragments the packet, it copies bytes of adjacent host memory into the fragments. Repeat that and you have a reliable host-memory leak from inside the guest, and Yibelo's write-up ("PwnEscape") shows a two-packet host crash and the lab escalation to root on top of it. KVM is the boundary that got crossed, not the code that was buggy. The vulnerable code was introduced in kernel 2.6.27, so effectively every host kernel before the fix was exposed. What to do with this: - Patch the host. The fix landed upstream on October 14, 2026; the first fixed stable kernels include 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113 and 6.18.57, and a host reboot is required. Patching the guest does nothing for this class of bug, because the flaw lives below the guest. - Treat it as a threat-model lesson, not just a patch instruction: snapshot and restore is a deployment optimization, not a security control. Your actual containment stack is the jailer, cgroup limits, host egress filtering, and keeping the host kernel patched. - Assume breach: log and monitor the host side too, because the boundary you trust the most deserves the most suspicion. - Calibrate the fear: no exploitation in the wild and no customer data impact has been reported for this CVE, and the write-up publishes the mechanism but not the full root chain or exploit code. Sources: - pwn.ai (Yibelo's write-up, part 1) - cve.org - vercel.com - aws.amazon.com (AWS: managed EC2, Lambda and Fargate not affected; self-managed KVM and Firecracker hosts are) - aws.amazon.com (related, same week: an auth bypass and two more issues in Loom for AWS, AWS's agent orchestration platform) Wrapping up You booted a hardware-isolated microVM in a fraction of a second, ran untrusted code inside it, froze it to disk, and brought it back to life in a new process. That loop, boot, snapshot, restore, is the core mechanic behind serverless cold starts done right. Natural next steps: the jailer for production hardening, vsock for host-to-guest communication without networking, and if you manage fleets of these, the Terraform provider for Firecracker to keep the host pools declarative.

CVE-2026-99999（PwnEscape）を読み解く──「KVMの脆弱性」ではなく、Linuxネットワークスタックの脆弱性 | 工程 | 担当 | |---|---| | 課題提示・取捨選択・内容チェック | 筆者 | | 原案作成・編成 | Claude Fable 5.1 | | 事実検証（検証メモ） | GPT-6 Astra | | 一次資料照合・最終稿 | Claude Fable 5.1 | 本稿は筆者個人の分析であり、所属組織や各事業者の公式見解ではありません。基準日は2026年10月21日（主要資料の確認は同日20:18〜20:45 JST）です。CVE・修正版・各事業者の対応状況は変動するため、適用判断時には原典と自環境を再確認してください。本文の参照番号 [n] は末尾「参照」の根拠URLに対応します。 :::note info 本稿での「確認」の範囲 本稿は公開資料の照合に基づくリスク検討であり、筆者による攻撃の再現試験や、各事業者の非公開構成の監査ではありません。研究者の実験結果、事業者の公表、筆者の分析を区別して書きます。※は本稿で確認できなかった事項を示し、「未修正」「非該当」「その事実が存在しない」のいずれも意味しません。資料を確認した日時と、公表・配布開始・メンテナンス・攻撃が発生した日時は区別します。「修正済み」「テスト提供」「配布予定」「評価中」「未確認」も分けて書きます。 ::: 結論 - 欠陥の所在はKVM本体ではなく、Linuxカーネルのネットワークスタックです。ゲストから渡された不正なチェックサムオフロードのメタデータが、ホスト側で検証済みのIPv4ヘッダを後から書き換えます。VMを使わないTUN／AF_PACKET経路も検討対象で、「Linuxゲスト自身には関係がない」という意味ではありません [3][15]。 - 公開報告には、ホストメモリ漏えい、ホストの可用性障害、ホスト側の管理者権限でのコード実行という実証範囲の異なる3種類の影響があります。Vercel本番Sandboxで実証されたのはホストメモリ漏えいで、クラッシュとコード実行は研究者所有環境での報告です。漏えいが確認されたことだけから、すべての環境でroot取得まで成立するとはいえません [13][15]。 - CVE-2026-99999は正式公開済みで、Linux CNAのCVSS v3.1基本値は9.3／Critical。mainlineおよび主要stable系列に修正が収録されています。 Debian（bookworm・trixieのsecurity）・Proxmox・Oracle Linux UEK・RHEL（10月20日公表の3エラッタ）・Google Container-Optimized OSの修正配布と、AlmaLinuxのテスト提供を区別して整理しました。クラウド基盤の状態は各社一律ではなく、AWSの対象管理サービスは非影響判定、Akamai／Linode・Hostinger・dataforest（Avoro含む）はホスト側の作業完了を公表、UpCloud・Hetznerは対応継続中、さくらのクラウドは10月20日に新規プロジェクト作成を再開しつつメンテナンスを順次実施する方針です。国内VPSでは、さくら・ConoHa・使えるねっと・KAGOYA・お名前.com・WebARENAが新規受付を停止し、ABLENETは停止せず新規収容ホストを対策済みとしています。受付再開や新規用ホストの対策を、全ホストの修正完了とは扱いません。 Google Cloud／OCIの管理基盤のサービス別対応完了は未確認（※）です。悪用については、Red Hatが「KEV active-exploit case」として扱う一方、CISA KEVカタログ（10月21日時点で2026.10.20版）には未収載で、CVEレコード内のCISA SSVCも評価時点ではExploitation: noneです。この三者を単純化せず第1節で並べます。AWSの管理サービスに関する影響なしの告知と、さくらの調査・受付制限は第5節で扱います。運用上は「影響し得るLinuxがどの階層にあるか」「誰が管理するか」「利用する配布先に修正があり、実際にそのカーネルで稼働しているか」を確認します [2][10][11][33][34][35][16]。 1. 事実関係の確認 CVEと修正 - CVE-2026-99999は正式採番・公開済み。 Linux CNAのレコードの公開日時は2026年10月15日12:19 UTC（21:19 JST）、状態は PUBLISHED、対象修正は 6785011f8b16。CNAによるCVSS v3.1基本値は9.3（Critical）、ベクターは AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H。 CNAが説明するゲスト→ホスト経路では、AV:Lはゲスト／仮想デバイス経由を意味し、通常のインターネット受信パケットだけによる攻撃ではありません。PR:Nはこの経路でホスト側の資格情報・capability・/dev/net/tun への直接アクセスが不要であるという評価で、ゲストが不正なメタデータを送れるという入力条件は必要です。VMを介さないTUN／AF_PACKETシナリオの権限条件まで不要になるわけではありません [1][2][30]。 - 修正コミット：torvalds/linux 6785011f8b16「ipv4: validate checksum_start before completing checksum」（作者 Michael S. Tsirkin、署名はRed Hatのメールアドレス／コミッター Jakub Kicinski、Cc: stable）。コミットメッセージの要旨は、不正なチェックサムメタデータがIPv4スタックに入ると skb_checksum_help がネットワークヘッダを壊し得ること、Paulosが発見・報告して他者も独立再現したこと、入口側の包括的な検証を今後の課題としつつ、まず完成処理の直前に防御的チェックを入れること、です [3]。 - Fixesタグの対象：f43798c（tun: Allow GSO using virtio_net_hdr、2008年7月）と bfd5f4a（packet: Add GSO/csum offload support、2010年2月）。CNAは影響開始版を2.6.27としています。AWSの告知には「4.4〜6.18の未修正カーネル」という別の範囲表記がありますが、これをLinux全体の影響版・非影響版を網羅した一覧とは扱いません。該当コードが存在することと実際に攻撃が到達することは別で、修正の有無・不正メタデータの入力可否・該当処理への到達性で決まります [4][2][10]。 - 変更6ファイル・保護5箇所：①include/net/ip.h に共通ガード ip_check_csum_start() を追加、②net/ipv4/ip_output.c の ip_do_fragment、③net/bridge/netfilter/nf_conntrack_bridge.c の nf_br_ip_fragment、④net/netfilter/nfnetlink_queue.c の nf_queue_checksum_help、⑤net/netfilter/xt_CHECKSUM.c の checksum_tg（CHECKSUMターゲット）、⑥net/xfrm/xfrm_output.c の xfrm_output。44行追加・12行削除 [3]。 /* include/net/ip.h に追加された共通ガード */ static inline int ip_check_csum_start(const struct sk_buff *skb) { if (unlikely(skb->csum_start < skb->network_header + ip_hdrlen(skb))) return -EINVAL; return 0; } /* ip_do_fragment() の修正後の順序：検査してから完成する */ if (skb->ip_summed == CHECKSUM_PARTIAL) { err = ip_check_csum_start(skb); if (!err) err = skb_checksum_help(skb); if (err) goto fail; } 評価主体別のCVSSとCISAの補足情報 10月21日時点の公開資料では、CVSS v3.1の評価は次のように分かれます。Linux CNAの9.3が8.8へ一律に変更されたわけではなく、各評価主体の前提・対象製品が異なります [2][37][36]。 | 評価主体 | CVSS v3.1基本値 | 必要な権限（PR） | 備考 | |---|---|---|---| | Linux CNA | 9.3 | PR:N（None） | CVEレコード [2] | | Red Hat | 8.8 | PR:L（Low） | 独自区分はImportant。ページに「preliminary and subject to review」と明記 [37] | | SUSE | 8.8 | PR:L（Low） | 別掲のCVSS v4.0は9.3 [36] | 上表はCVSS v3.1の比較です。SUSEが別に掲載するCVSS v4.0の9.3とは区別します。ベンダー独自の重要度区分と、CVSS基本値も同一ではありません。PR:NとPR:Lの差は、ゲスト内で不正メタデータを送るのに必要な権限をどう数えるかの差であり、ホスト側の資格情報が不要という点は共通です。 CVEレコードの時刻は、公式JSONのフィールドごとに分けて読みます [2]。 | 対象（JSONのフィールド） | 日時 | 内容 | |---|---|---| | レコード全体の最終更新（cveMetadata.dateUpdated） | 10月19日21:19 UTC（20日06:19 JST） | 下記CISA ADPコンテナの更新に連動 | | Linux CNAコンテナ（cna.providerMetadata.dateUpdated） | 10月19日09:27 UTC（18:27 JST） | mainline修正版の表記が 7.3-rc7 から正式版 7.3 に。stable各系列の修正版・CVSS・参照URLは不変（10月17日11:14 UTCの更新では内容変更なし） | | CISA ADPコンテナ（adp.providerMetadata.dateUpdated） | 10月19日21:19 UTC（20日06:19 JST） | CWE-20（Improper Input Validation）の problemTypes を追加。直前版（10月19日09:27 UTC時点）との差分で、この更新の変更点はCWE-20の追加のみと確認 | | SSVC評価内容（ssvc.content.timestamp） | 10月16日15:49 UTC（17日00:49 JST） | Exploitation: none、Automatable: no、Technical Impact: total。この更新で変更なし | CISA ADPコンテナが10月20日（JST）に更新されたことを、CISAがその時点で悪用状況を再評価して「none」と判定したという意味に読まないでください。SSVCの値は10月16日時点のフィールド値であり、研究者の実証を否定したり、悪用の不存在や安全な猶予期間を保証したりする情報ではありません。 悪用に関する評価：Red HatとCISAを区別する Red HatのCVEページには悪用に関する記載があります。以下は各資料の記載を並べたもので、差異の理由を推測して整合させたものではありません [37][44][2]。 | 資料・評価主体 | 確認した記載 | 本稿での扱い | |---|---|---| | Red HatのCVEページ | Statementに「Red Hat tracks this flaw as a KEV active-exploit case.」と記載。緩和策は「利用不可またはRed Hatの基準を満たさない」とする [37] | Red Hatがこの扱いとしていることを確認。根拠となる具体的な攻撃事例・被害組織・発生日時・記載の追加日時は未確認（※） | | CISA公式KEVカタログ | 10月21日時点で取得できるJSONの catalogVersion は 2026.10.20（dateReleased 10月20日19:00 UTC＝21日04:00 JST、1,754件）。10月20日に追加された6件に本CVEは含まれず、この版でも収載を確認できなかった（全件を機械照合） [44] | Red Hatの表記を根拠に「CISAのKEVへ追加済み」とはしない。取得した版の確認であり、将来の追加や悪用の不存在を判断したものではない | | CVEレコード内のCISA SSVC | 10月16日15:49 UTCの評価で Exploitation: none 等を掲載。10月19日21:19 UTCのCISA ADP更新ではCWE-20の追加のみで、SSVCは再評価されていない [2] | その時点の評価として示す。Red Hatの記載を否定する根拠や、現在の悪用の不存在・安全な猶予期間の保証として使わない | 「悪用情報はない」「CISAがKEVへ追加した」「広範な実攻撃が確認された」のいずれにも単純化しません。上記は本稿の資料確認時点（10月21日）の記載であり、攻撃の発生・公表日時ではありません。CVEレコード本体（CNA・CISA ADP・SSVC）は10月19日21:19 UTC以降に変更がありません。具体的根拠や評価差の理由は未確認（※）のままとします。 Vercelの公表との整合 - Vercelは「Linuxカーネルのゼロデイ1件」を最重要の発見とし、Paulos Yibelo（pwn.ai）が特別なアクセス権を付与されていない標準Sandboxからネットワークスタックの欠陥を見つけたこと、クラッシュとコード実行は研究者自身のKVM/Firecracker環境で実証されたこと、主要クラウドの多くが同じ層で顧客ワークロードを分離しているため共有インフラのリスクであることを述べています。募集時の脅威モデルはコンテナ内root・microVM内カーネルアクセスまで想定しており、「ゲストOS内でも非特権だった」という意味ではありません [13][14]。 - 初期報道には「メモリ漏えいとホストクラッシュの2件の独立した欠陥」とする説明がありましたが、10月14日のVercel公式はひとつのネットワーク欠陥から漏えい・クラッシュ・コード実行を説明しています [32][13]。 - Vercelの数字：受付報告1,285件、有効報告57件、支払済み報奨総額242,000ドル、Critical 1件。研究者個人への報奨額は報道で50,000ドル（チャレンジの1報告当たり上限と同額）とされますが、実支払額を示す一次資料は未確認（※）[13][14][32]。 :::note warn 呼称の注意 「KVM escape」という呼称は、研究者の実証でゲスト／ホスト境界を越えたという意味であり、脆弱性の所在はKVMではありません（記事自身がFigure 1で明記、修正対象もIPv4・netfilter・xfrm）。初期報道にはKVM自体の欠陥かどうか不明とする混乱が残っているため、記事タイトルに引きずられないようにしてください [3][15]。 ::: 2. 技術的メカニズムの要点 1. CHECKSUM_PARTIAL はskbに「後で csum_start + csum_offset の位置へチェックサムを書く」約束を持たせます。ゲストはvirtio-net headerでこの値を指定できます。これはIPv4ヘッダチェックサムのオフロードそのものではなく、不適切な位置指定によってネットワークヘッダが書き換わる点が問題です [26][15]。 2. 研究者が指摘した入口（__virtio_net_hdr_to_skb）の従来の最小長検証は、skb->data 相対の条件だけでは、L2ヘッダ除去後の「ネットワークヘッダ相対」の位置関係を保証していませんでした（座標系のズレ）[15][3]。 3. ホスト側の出力フラグメント処理 ip_do_fragment() では、従来「チェックサム完成 → IPヘッダ取得・ihl読み出し」の順だったため、遅延書き込みがIPv4ヘッダ先頭（例：0x45→0x4f、IHL 5→15語）を書き換え、すでに20バイトとして検証・ルーティング済みのヘッダを60バイトとして再解釈させます [15][3]。 4. 研究者の試験ケースでは、論理的な線形データ28バイトに対して60バイトのヘッダコピーが起きるため、差分の32バイトがホストメモリとして「IPオプション」に乗って外に出ます（アロケータの物理境界ではなく、skbの論理境界に対するOOB read）。32バイトはこのケースの値であり、固定量・上限ではありません [15][3]。 | パケットの見え方 | 先頭バイト | IHL | 解釈されるIPv4ヘッダ長 | |---|---|---|---| | 解析時の状態 | 0x45 | 5語 | 20バイト | | 遅延書き込み後 | 0x4f | 15語 | 60バイト | 以下は研究者が説明したIPv4フラグメント経路の模式図で、すべての構成に共通する処理順を示すものではありません [15][3]。 flowchart TD A["低信頼入力<br/>パケット＋部分チェックサム情報<br/>(csum_start / csum_offset)"] --> B["オフロードメタデータをskbに設定<br/>(CHECKSUM_PARTIAL)"] B --> C["L2処理／L3正規化"] C --> D["IPv4解析・再組立・ポリシー・経路<br/>ヘッダをIHL=5(20B)として信頼"] D --> E["ip_do_fragment()"] E --> F["skb_checksum_help()<br/>保留中の書き込みが解析済みヘッダを変更<br/>0x45 → 0x4f"] F --> G["同じ関数内で変更後のIHLを使用<br/>ヘッダが60Bを主張"] G --> H["論理線形データ(28B)を超える<br/>60Bのヘッダコピー"] H --> I["送出IPv4オプションに<br/>ホストメモリ32Bが混入"] F -. 修正後はここで検査 .-> X["ip_check_csum_start()<br/>csum_start < network_header + ip_hdrlen<br/>なら -EINVAL で破棄"] style F fill:#c7381f,color:#fff,stroke:#c7381f style I fill:#c98a1b,color:#fff,stroke:#c98a1b style X fill:#1b2a41,color:#fff,stroke:#1b2a41 要するに「同じパケットを、カーネルの別々の箇所が別々の状態として信頼した」というTOCTOU型の問題です。スレッド競合ではなく、検証と後続利用の間に遅延書き込みが入る決定論的な処理順の問題として説明されています。研究者はこのパターンを「deferred-metadata trust inversion」と呼ぶ一方、構成要素には既知の技術が含まれるとも述べています。この名称と新規性評価は研究者の主張であり、確立した分類名や、他のプロトコル・製品の脆弱性を示す証拠とは扱いません [15][2]。 3. リスク評価 攻撃者の立場・条件 - 必要なのは、不正なオフロードメタデータ付きフレームを受け入れる入口（virtio-net→TAP、またはTUN／PACKET_VNET_HDR 付きAF_PACKET）と、未修正Linux側で該当する完成処理に到達する経路の両方です。ゲストrootは典型条件ですが普遍的な十分条件ではなく、ハイパーバイザのバグは不要です [2][3]。 - 公開修正で保護された到達先は5箇所（ip_do_fragment、ブリッジconntrackのフラグメント、NFQUEUE、CHECKSUMターゲット、xfrm出力）。典型的にはホストがゲストトラフィックをルーティング／NATしてIPフラグメントする構成が検討対象になりますが、製品の「default NAT」といった名称だけで成否は決まりません。逆に、ブリッジconntrackを通る構成もあるため、「L2ブリッジだから安全」という名称による判定もできません。これらは公開修正の保護対象であり、関連するすべての変種を網羅した必要条件の一覧とはしません [3][15]。 - VMなしでも成立しえます。 研究者の初期パッチ説明は、VMゲストを必要とせずvirtio-net headerを扱うTUNデバイスで足りると明示しており、AF_PACKET側の検証修正も含まれています。コンテナ／user namespaceからの到達性は、TUN作成に関わる CAP_NET_ADMIN、AF_PACKETソケット作成に必要な CAP_NET_RAW（そのnetwork namespaceを管理するuser namespace内）、渡されたファイル記述子、後続経路の各条件で決まります。標準的なコンテナ設定での完全な攻撃成立は未確認（※）[15][7][27][28]。 影響の深刻度 | 報告された影響 | 実証状況 | 意味 | |---|---|---| | ホストメモリ漏えい（試験ケースで32バイト／回） | 研究者が対照実験つきで再現。Vercelは本番Sandboxでのホストメモリ漏えい実証を公式に認めている（同社によれば、顧客データへのアクセスを示す報告はなかった）[15][13] | マルチテナントで「機密性」の侵害。後続攻撃でのKASLR／ヒープ状態の推定に使える可能性があるが、任意位置の読み出しや他テナントのデータ取得が実証されたわけではない | | ホストDoS | 研究者所有のLinux 6.12および7.x系ホストで確認（記事原文の記述）。サブバージョン・設定の全範囲での再現性は未確認（※）[15][13] | 当該Linuxがクラッシュ等で停止すると、そのカーネルに依存するVM群に停止・利用不能が及びうる。ネストした中間ホストや単一VM内のLinuxであれば、直ちに下位の物理ホストや他テナント全体の停止を意味しない | | 64バイトの選択的カーネル書き込み→ホストroot | 研究者は、自身のKVM実験環境でホストroot権限のヘルパーを実行し、別々のコールドブート4回で再現したと報告。Vercelもクラッシュ・コード実行は研究者所有機での実証と区別している [15][13] | 研究者の実験環境におけるゲスト→ホスト境界侵害の報告。任意アドレスへの汎用的な書き込み、任意構成での成功率、ベンダー本番環境でのroot取得まで確認されたとは扱わない | エクスプロイトの流通見込みと悪用評価 確認した研究記事のPart 1は完全なエクスプロイトコードを掲載しておらず、ホスト制御までの過程を扱うPart 2を予告しています。第三者を含む全公開場所でPoCや続編が存在しないことまでは確認していません（※）。研究者は、比較的弱い構成向けは数週間、デフォルト構成向けは1か月以内にエクスプロイトが現れると予測していますが、対象となるデフォルト構成の全範囲や、実際の完成・流通時期が確認されたわけではありません。筆者のリスク判断としては、この予測を期限や安全な猶予期間とみなさず、公開済みの修正と自組織の露出条件に基づき更新を優先します [15]。 公開コード・続編の確認状況と、現実の悪用に関する評価は別です。第1節の悪用評価のとおり、Red Hatには悪用に関する記載がある一方、具体的な攻撃事例やCISAのKEV収載は本稿では確認できていません。研究者所有環境での実証を、実際の攻撃の発生やベンダー本番環境でのroot取得へ読み替えません [37][44][13][15]。 誰が当事者か - 評価対象：Linuxカーネルをホストとし、virtio-net／TAP等を通じてゲストのメタデータを受け入れる仮想化・サンドボックス基盤（KVM/QEMU、Firecracker、Proxmox、OpenStack、oVirt、Linux上で動くcrosvm等のVMM、AIエージェント用サンドボックス）。Linuxホストであることは該当性の十分条件ではありません。 修正状況、仮想NIC、メタデータ受け入れ、Linux skb経路、後続処理の確認が必要で、製品名だけで影響を確定しません。vhost-user／DPDK／SR-IOV等を使う場合も、技術名だけではなく、対象トラフィックが問題のLinux skb処理を通るか、途中でTAP等へ戻るかを調べます。VMを介さずTUN／AF_PACKET入力を扱うLinuxも別途評価対象とします [2][25][19]。 - 非Linuxの基盤と、その上のLinuxを区別する：VMware ESXiのVMkernelやWindows Hyper-V自体は、今回のLinuxコードの直接の修正対象ではありません。Azureの基盤もMicrosoftはWindows Hyper-Vベースと説明しています。Linux VMを動かしているだけで、その収容先のESXiやHyper-Vの物理ホストが本件で脆弱になるわけではありません。 ただし、ゲスト内LinuxでTUN／AF_PACKET等から該当処理へ到達できる場合や、そのLinuxがさらにKVM等のホストになっている場合は、そのLinux自身の影響を別途評価します。どのLinuxが侵害されるのかと、どの境界を越えるのかを分けて判断します [3][2][22][27][28]。 - gVisor／Kata Containers：gVisorは独自のユーザー空間網スタックを持ちますがホスト接続方式で境界が異なり、KataはVMを使うため選択したVMM・ホストカーネル・バックエンドの評価が必要です。「コンテナだから対象外」「VM型だから全て対象」のいずれも不適切です（構成別影響判定は未確認※）[23][24]。 - IPv6：採用済み修正とIHL書き換えによる漏えいの実証はIPv4が対象です。原記事は、入口検証の議論にはIPv6や入れ子のヘッダ等も関係すると説明していますが、本稿ではIPv6で同等の漏えい・root取得が実証されたことは確認していません（※）。これは「IPv6には関連する問題がない」という確認ではなく、IPv6への切替だけで安全になるとの結論も導けません [3][15]。 自組織のLinuxが評価対象かを判定する流れを図にすると次のようになります。 flowchart TD Q1{"そのLinuxは<br/>virtio_net_hdr付きの入力を受けるか？<br/>(virtio-net→TAP / TUN / AF_PACKET+PACKET_VNET_HDR)"} Q1 -- いいえ --> N1["この実証経路では評価対象外<br/>(別の入力経路がないか確認)"] Q1 -- はい --> Q2{"修正を含むカーネルで<br/>実際に稼働しているか？<br/>(インストール済み≠実行中)"} Q2 -- はい --> N2["本CVEは修正済み<br/>後続の入口側検証を監視"] Q2 -- いいえ --> Q3{"低信頼側の入力が<br/>5つの完成処理のいずれかに到達するか？<br/>IPv4フラグメント / ブリッジconntrack /<br/>NFQUEUE / CHECKSUMターゲット / xfrm"} Q3 -- 到達しない --> N3["露出は低いが保証ではない<br/>記事は他経路の存在にも言及<br/>→ 更新を優先"] Q3 -- 到達する／不明 --> N4["影響する構成<br/>修正済みビルドへ更新・再起動<br/>多テナントは可用性も評価"] style N4 fill:#c7381f,color:#fff,stroke:#c7381f style N2 fill:#1b2a41,color:#fff,stroke:#1b2a41 style N3 fill:#c98a1b,color:#fff,stroke:#c98a1b 4. 修正・配布の現状（10月21日時点） 以下は公表資料で確認できた配布先・ビルドの状況であり、各製品の全系列を網羅した一覧ではありません。「テスト提供」と「正式配布」、「配布予定」と「提供済み」を区別し、本番環境への適用は契約・サポート範囲と変更管理手順に沿って判断してください。 | 対象 | 状況 | |---|---| | mainline | 10月8日にJakub Kicinskiがnet.gitへ適用（patchwork bot通知）。同日のLinus宛てpull要求（Networking for v7.3-rc7）が10月9日にマージ（マージコミット af32da41、タグ net-7.3-rc7）。pwn.ai記事の「10月14日マージ」は公開履歴と整合しない [5][6][15] | | stable／mainline正式版 | CNAレコードに示された各stable系列の修正版は 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.57、7.2.11（いずれもkernel.orgのリリース日は10月15日）。10月15日のリリースについては6.1.190・7.2.11の変更履歴でも対象修正を確認。mainlineの正式版は7.3（kernel.org掲載のリリース日：10月18日）で、CNAレコードも10月19日の更新で修正版表記を 7.3 に改めた。既存のstable／ベンダー系列に修正があれば、7.3への一律移行は不要。7.0／7.1への個別backportは本稿では未確認（※）で、「7.x全体が修正済み」という意味ではない [2][9][56] | | Amazon Linux | AWS Security Bulletin 2026-137-AWSは10月15日10:30 PDT（16日02:30 JST）公開。AL2：kernel-4.14.355-287.750.amzn2、kernel-5.4.302-229.494.amzn2、kernel-5.10.269-270.1108.amzn2、kernel-5.15.220-156.256.amzn2。AL2023：kernel-6.1.188-233.385.amzn2023、kernel6.12-6.12.110-135.201.amzn2023、kernel6.18-6.18.51-120.162.amzn2023。告知はこれら以降を修正済みとしている。upstreamより小さいベース版数でも、修正がbackportされている場合がある。 自己管理する対象ホストについて、更新パッケージの適用と再起動を案内しており、回避策は示していない [10] | | Debian | bookworm・trixieのセキュリティ更新、およびforky・sidの掲載版で修正済み。 公式トラッカーのソースパッケージ linux では、bookworm（security）6.1.190-1、trixie（security）6.12.113-1、forky／sid 7.2.11-1 が fixed。bookwormの修正にはDLA-4841-1が対応し、Debian LTSの告知一覧では10月17日付（告知メールの送信時刻は未確認※）。trixieはDSA-6568-1（10月16日13:39 UTC＝22:39 JST）で告知。一方、古い通常リポジトリの掲載版であるbookworm 6.1.176-1、trixie 6.12.107-1 には vulnerable 表示が残る。リリース名だけでは安全判定せず、更新元・適用済みビルド・実行中のカーネルを照合する。 本表はDebianの全カーネルパッケージ・全系列を網羅していない [11][33][45] | | Ubuntu | 公式ページには引き続き Needs evaluation のカーネル系列がある。評価待ちを「脆弱と確定」「修正済み」のいずれにも読み替えない。 リリースとカーネルフレーバーごとの状態を確認する。本稿では全系列の修正ビルドを網羅確認していない（※）[12] | | Proxmox | 公式フォーラムのスタッフ回答（投稿#2）で、proxmox-kernel-7.0.14-24-pve（および -signed）に修正を収録し、pve-no-subscription まで提供済みと確認できる。pve-enterprise は同回答では「近日中」。投稿#4には「enterpriseでも取得可能になった」というProxmox Subscriber（非スタッフ）の利用者報告があるが、メーカーによる配布完了の確認、またはenterpriseリポジトリのパッケージ一覧との直接照合には至っていない（※）。公式フォーラム上の利用者報告とメーカー確認は区別する。これはProxmoxの個別ビルドの情報で、upstream 7.0系列全体の修正を意味しない。同回答は、現在サポートされているカーネル系列は7.0.14系のみで、サポート終了の系列・製品リリース（PVE 8向けを含む）には更新を出さないとも説明しており、旧系列の利用者はサポート状態と移行先も確認する [35] | | AlmaLinux | 8／9／10向けのテスト提供を確認。公式記事の初回公開は10月16日20:17 UTC（17日05:17 JST）。提供先は almalinux-testing で、記事は本番リポジトリへの移行前の検証を呼びかけている。8：kernel-4.18.0-553.174.2.el8_10、9：kernel-5.14.0-687.57.2.el9_8、10：kernel-6.12.0-211.66.2.el10_2。Kitten 10は次回の通常更新に含める予定。本番用の正式配布完了とは区別する。 AlmaLinuxの提供状況をRHEL／Rocky Linuxへそのまま当てはめない [34] | | Oracle Linux（UEK） | Oracle LinuxのCVEページとエラッタで、UEK向けの修正を10月16日公表と確認。UEK R6（OL7・8）：5.4.17-2136.360.3.1／ELSA-2026-500397、UEK R7（OL8・9）：5.15.0-325.221.6.4／ELSA-2026-500398、UEK R8（OL9・10）：6.12.0-207.111.5.4／ELSA-2026-500399（例：kernel-uek-6.12.0-207.111.5.4.el9uek）。実パッケージ名にはOS系列・アーキテクチャの識別子が付く。Oracle Linuxの修正配布は、OCI管理基盤への適用完了の証拠ではない（第5節）[54] | | SUSE | 公式CVEページの総合状態は Pending。製品別には Affected が掲載され、Not affected・修正済みの項目はない。同ページには対応するSecurity Announcementの紐付けがない（「No SUSE Security Announcements cross referenced.」）。影響評価を確認できたことと、修正配布を確認できたことは別で、製品・サービスパック別の修正版は引き続き個別確認が必要（※）[36] | | RHEL | 10月20日公表の3件のエラッタ（いずれもImportant、本CVEを唯一のSecurity Fixとして収録、要再起動）を確認。 RHSA-2026:86033：RHEL 9（EUS 9.8、Update Services for SAP Solutions 9.8、CodeReady Linux Builder等を含む、x86_64／s390x／ppc64le／aarch64）向け kernel-5.14.0-687.59.1.el9_8 [72]。RHSA-2026:86089：RHEL 9.4のAUS／Update Services for SAP Solutions／4 years of updates／Extended Life Cycle向け kernel-5.14.0-427.157.1.el9_4 [73]。RHSA-2026:85979：RHEL 10.0 EUS／4 years of updates（CodeReady Linux Builder 10.0 EUS含む）向け kernel-6.12.0-55.112.1.el10_0 [74]。対象契約・製品・アーキテクチャは各エラッタの掲載範囲に限り、上記を全RHEL系列への無条件な提供とは扱わない。Red HatのStatementは追跡する全製品ストリームを影響ありとし、緩和策は「利用不可またはRed Hatの基準を満たさない」としている。CVSS（暫定）と悪用に関する記載は第1節で区別 [37] | | Rocky Linux | 製品・系列別の正式な修正済みビルドは本稿では確認できていない（※）。RHELのエラッタ、AlmaLinuxのtesting、第三者ライブパッチの提供を、Rocky Linuxの正式な修正配布の証拠として代用しない [34] | | Google Container-Optimized OS（COS） | COS 129／125／121の10月19日付リリースノートで「Fixed CVE-2026-99999 in the Linux kernel」を確認。 対象イメージは cos-129-19506-549-22、cos-125-19216-739-16、cos-121-18867-638-13。これは利用者がGCE／GKEノードで選択するゲストOSイメージの修正提供であり、Google管理の物理ホスト・既存GKEノード・利用者環境への適用完了の公表ではない（第5節）[75] | | ライブパッチ | テスト提供、展開中の説明、正式な本番提供を区別する。CloudLinux／KernelCareの公式ステータスページ（10月16日17:34 UTC＝17日02:34 JST更新）は、パッチセットと配布先を個別に示している：K20261016_0002（AlmaLinux 9／CloudLinux 9）はmain feedに提供済み、K20261016_0001（RHEL 9）・K20261016_0004（Oracle Linux 9）・K20261016_0005／0006（Rocky Linux 9）はtesting、それ以外は作業中。10月17日以降の追加更新はない [55]。main feed提供済みはAlmaLinux 9／CloudLinux 9向けに限られ、他の対象は公式ステータス上もtestingまたは作業中である。一方、TuxCareの記事（10月16日時点）は「no rebootless patch for this CVE has been released」とし [38]、CloudLinuxのブログ記事には「rolling out」と「No livepatch has shipped yet.」が併存し「[NEEDS: KernelCare status per release]」という編集用注記も残る [46]。本稿は公式ステータスの明示内容を優先し、他の対象を含む全面提供や、個々のカーネルビルドへの適用可能性・適用成功は未確認（※）とする。kpatch／Ksplice等の本CVEへの対応ビルド・適用状態も未確認（※）。仕組みの導入済みと、このCVEの修正が実際に有効なことは別である | | 入口側（virtio_net_hdr検証）の後続修正 | 採用済みコミットは、より包括的な入力検証には追加の作業が必要と説明している。公開メーリングリスト上では、10月7日のWillem de Bruijn案に10月8日に再提出要求（Changes Requested）があり、10月15日にTsirkinによるv2系列（7本）がnet-nextに投稿された。[PATCH net-next v2 4/7]「net: resolve uncommon partial checksums at ingress」では、通常のTCP／UDPとして扱えない部分チェックサムを入口で完成させる案などが議論されている。これは投稿された案であり、採用済み仕様とは扱わない。10月17日のnetdev日次一覧には、virtioのチェックサム入力処理を検査するselftestのRFC案と返信、および名前空間ごとの検証設定と無効化権限に関する議論の継続が記録されているが、本稿では日次一覧・個別メッセージの本文を取得できていない（※）[39][47]。10月19日12:03 UTC（21:03 JST）に、Tsirkinが [PATCH net v3 0/8] more virtio-net csum hardening（8本）を投稿。 カバーレターによれば、信頼できないハードウェアが CHECKSUM_PARTIAL の開始位置・オフセットを指定できる問題に対し、実際のチェックサムフィールドだけを編集するか、スタックが参照する前にチェックサムを完了させる方針で、net向け3本（ingressでの状態の計上、ingress時の不完全なチェックサムの解決、検証を無効化するsysctl）、net-next送り可のクリーンアップ（ip4_parse() 追加、virtio_netのプロトコル計算整理）、UML vector関連2本、トンネルのcsum_start解析を含む。投稿者自身は「Somewhat tested, tunnel also tested now, um part compiled only」とし、UML部分はコンパイル確認のみ。同日13:26（lkml.iu.edu表示、米東部時間）にChris Argesが、テストでKASANエラーが出なくなったとして Tested-by を付けて返信したが、UML（um）関連パッチは未テストと明記 [61][62]。10月20日22:32（同）にJakub Kicinskiが、パッチ6の未宣言シンボル（virtio_net_hdr_csum_check_disabled_key、static化の提案）とパッチ7の ip4_parse のkernel-doc警告を指摘（受理・却下の判断は含まない）[76]。10月21日03:55（同）にTsirkinが [PATCH net v4 0/7]（7本）を投稿。 v3からの変更は、UMLの変換失敗処理の統合（Björn Töpelの指摘）、tap・virtio_netのカウント追加、ループバックでもフレームを走査する変更、トンネル経路・IPバージョン読み取りの修正、sysctlの virtio_net_hdr_validate への改名と解析前のopt-out確認、ビルド警告の修正、ip4_parse() のkernel-doc追加。投稿者は「Tested: full suite on the final tree, tunnel included.」とする一方、「um part compiled only.」と引き続きUML部分はコンパイル確認のみ [77]。これらは投稿案・レビュー・テスト報告であり受理通知ではなく、系列全体の受理・mainline収録・stable配布完了は未確認（※）。 採用済みのIPv4側修正と入口検証の追加案は区別し、後続案を待つことを配布済み修正の適用延期の理由にしない [3][8] | 5. クラウド事業者の対応状況 以下の日時は、特記しない限り各社の公表・更新日時であり、本稿の確認日時ではありません。「非影響判定」「ホスト側修正完了」「対応中」「利用制限」「未確認」を混同せず、サービス範囲・管理階層を明示します。告知の掲載継続を、実際の対応が進んでいない証拠とは扱わず、各告知のサービス範囲を越えて影響の有無を一般化しないでください。 :::note warn 完了判定の単位 事業者名ではなく「サービス × 管理階層 × 対象範囲」で記録します。ゲストOSの修正配布、CSPホストの適用完了、新規受付の再開は、それぞれ独立した確認項目です。「ホスト側修正完了」は利用者のゲストOSも更新済みという意味ではなく、OS製品の修正版公開はクラウド全ホストへの適用完了を意味しません。 ::: 主要クラウド：事業者の基盤と利用者管理OSを分ける - AWS：「EC2インスタンス、Lambda、FargateなどAWS管理のコンピュート・コンテナサービスは影響なし、利用者の対応不要」と明記。影響対象は「virtio-netとKVMで自己管理するVM（Firecracker等のVMM利用を含む）を未修正ホストで動かしている利用者」。Nitroは「KVMを基に独自開発・最小化したハイパーバイザ」というAWS自身の説明があり「KVMベース」は妥当ですが、一般的なLinux＋QEMU＋TAP／vhost-net構成と同じデータ経路だと推定するのは不適切です。Vercel Sandboxはbare-metal EC2上に自前のFirecracker基盤を構築しているため、Vercelのホストで実証されたこととAWS管理サービスが影響なしという告知は矛盾しません [10][18][14]。 - さくらのクラウド：10月16日から一時停止していたプロジェクトの新規作成を、10月20日（火）より再開し、新規プロジェクト作成を含めサービスの各機能は通常どおり利用できると告知を更新しました（正確な再開時刻は※未確認）。10月19日に明示されたメンテナンス方針（本件に関するメンテナンスを順次実施し、対象者へ実施日の1週間前を目途に登録メールアドレス宛てに日時・影響を通知）は維持されています。受付再開を、全ホストの修正適用完了とは扱いません。 全体の修正完了、個別環境の作業日時・停止時間は公開告知だけでは確認できません（※）[16]。 - さくらインターネットの全社告知：10月16日17:00時点の発表に、10月20日19:15の追記（18:30時点の情報）が加わりました。追記は「さくらのクラウド」の新規プロジェクト作成再開と、「さくらのVPS」告知のタイトル・内容の一部修正（影響範囲は変更なし）を案内。対象サービスとして、さくらのクラウド・さくらのVPS・さくらのレンタルサーバ・高火力DOK・高火力VRTを挙げ、影響の有無および影響範囲の確認を引き続き進めているとしています。利用者がOSを管理するサービス（専用サーバPHY等）は提供元の更新情報を確認するよう案内。対象一覧への掲載を、各サービスの脆弱性や侵害の確定とは扱いません [17]。 - Google Cloud：Compute EngineがKVMベースのハイパーバイザを使うという公表は確認できますが、全体・Compute Engine・GKEのセキュリティ告知一覧から、管理基盤に関する本CVEの個別サービスの影響判定・対応完了は特定できていません（※）。一方、ゲストOSイメージとしてはContainer-Optimized OS 129／125／121に本CVEの修正を含むイメージが10月19日付で提供されています（第4節）。これは利用者がノードに選ぶイメージの修正であり、Googleの物理ホストや既存GKEノード全体への適用完了ではありません。KVM採用だけから影響を確定せず、告知が見つからないことを非該当・未対応・修正済みのいずれの証拠にもしません [20][42][57][58][75]。 - OCI：KVMを利用する基盤という公表と、本CVEのサービス別影響・ホストへの適用完了は未確認（※）という整理を分けます。Oracle Linux UEKの修正配布（第4節）を、OCI管理基盤全体の修正完了へ読み替えません。 個別構成・対応状況は、必要に応じ契約窓口のService Requestで確認します [21][43][54]。 - Azure：Microsoftは基盤ハイパーバイザをWindows Hyper-Vベースと説明しており、本件のLinuxコードを根拠に、その物理ホストの脱出を主張することはできません。ただし、利用者が運用するLinux VM自身や、その中の自己管理仮想化・サンドボックスは別途評価します。これは基盤の公表に基づく技術的整理であり、Azureの全サービスについて本CVEの個別影響判定を取得したという意味ではありません [22][3]。 国内VPS・ホスティング：停止対象の操作を限定する | サービス・告知日 | 利用制限・対応 | 既存利用・留保 | |---|---|---| | さくらのVPS（10月16日付、同日18:10追記） | 石狩・東京・大阪の全リージョンで、全プランの新規申し込み、スケールアップの受付、利用者が持ち込むISOでのインストール、さくらのクラウドへのマイグレーション機能を一時停止 [40] | 契約中のプランは通常どおり稼働。再開時期は未定。全社告知の10月20日追記は、VPS告知のタイトル・内容を一部修正したが影響範囲に変更はないとする。クラウドのプロジェクト作成再開を、VPSの受付再開とは読まない。 クラウド向けの「約1週間前通知」を、VPS共通の確定方針ともしない。メンテナンス：ソフトウェアメンテナンス39837（東京・大阪・石狩の一部およびfor WindowsServerの一部、10月20日21:00〜21日03:00、ホスト再起動を伴う）は10月21日02:03に完了 [68]。続いて緊急メンテナンス39864（東京・大阪・石狩の全リージョンおよびfor WindowsServer大阪・石狩、10月21日15:00〜22日18:00）を実施中で、ホストサーバを順次再起動、1VPSあたり約1時間の停止（通信断、再起動は原則なし）、39837実施済みのVPSは対象外。理由は「障害によるデータ消失や長時間のサービス停止を未然に防ぐため」とされ、いずれの個別告知にもCVE-2026-99999やセキュリティへの言及はない [67]。メンテナンス後にntpdが停止する場合の再起動手順を案内 | | さくらのレンタルサーバ等（10月16日付） | レンタルサーバ・メール専用プラン・マネージドサーバの新規申し込み受付を一時停止 [41] | 契約中のプランは通常どおり稼働、再開時期は未定。受付制限の対象が広いこと自体を、各サービスの侵害が確定した根拠とは扱わない | | ConoHa VPS（10月19日付） | 新規申し込みの受付を一時停止。契約中の利用者によるVPSの追加作成は可能 [48]。10月21日時点でも告知に追記はなく、公式の申込停止画面に「ただいま 新規お申し込みを停止しています」と表示 [63] | 利用中VPSの停止・利用制限は現時点でなく、再開時に改めて告知するという内容。正確な受付停止開始時刻は未確認（※）。WING等の他サービスまで拡張しない | | ABLENET VPS（10月20日付。10月16日付の影響確認告知を更新） | 新規注文でゲストを収容するホストは対策済みとし、既存ホストへの対策は順次進めると告知。新規申し込みの停止は現時点で予定していない [49] | 完了時期、再起動・メンテナンスの日時、利用者側作業の案内はない。利用者対応が必要になった場合や影響が確認された場合は速やかに知らせるとする。新規用ホストの対策済みを、既存ホストを含む全面的な修正完了とはしない（作業の正確な完了時刻は※未確認） | | 使えるねっと（10月18日付） | 10月18日からVPSの新規申し込み受付を停止。既存契約者による追加申し込みも停止対象。 対象は使えるクラウドVPS VM（Linux／Windows、全プラン）、VM＋Plesk（同）、FX専用VPS（全プラン）[59] | 理由はCVE-2026-99999への対応（仮想サーバーを動かす基盤に影響するおそれ）。再開時期は未定。既存VMへの影響は記載なし。Linux・Windowsを含むのはサービス上の受付制限であり、Windowsカーネル自体の欠陥や既存VMの停止を示すものではない | | KAGOYA（10月19日付） | 10月19日18:00から新規申し込みの受付を一時停止。 対象はKAGOYA CLOUD VPS、KAGOYA MAIL（ブロンズ・シルバー）、レンタルサーバー、desknet's NEO専用サーバー、KAGOYA Chat [65] | 理由はCVE-2026-99999の影響調査と必要な対策。利用中のサービスは通常どおり利用可。既存アカウントでの追加作成の可否は記載なし（※）。再開時期は未定 | | お名前.com VPS（KVM）（10月19日付） | 10月19日16:00からVPS（KVM）全プランの新規申し込み受付を一時停止 [66] | 理由はCVE-2026-99999の公開。利用中のVPS（KVM）は、この受付停止によって停止や利用制限を受けない（制限が必要になれば改めて通知）。再開時期は未定。同社デスクトップクラウドの不正アクセス事案（下表）とは別の告知 | | WebARENA（10月21日付） | 10月21日から新規申し込みを一時停止。 対象はWebARENA Indigo、IndigoPro、SuitePRO V4、Wasabi [64] | 理由はCVE-2026-99999の公開に伴う影響確認。既存インスタンスの利用とインスタンスの追加は通常どおり可能。 IndigoProは既存契約へのサービスID追加、IndigoProとSuitePRO V4はスペック変更も可能。影響の有無・範囲は確認中。再開時期は未定。Wasabi（オブジェクトストレージ）をVPSと分類しない | 本CVEとの関係が未確認のメンテナンス・事案 次の事項は、取得した告知が本CVEを明記していないか、原因が特定されていないものです。本CVEの対応・悪用事例として算入しません。 | 事業者・事案 | 公表内容 | 本稿での扱い | |---|---|---| | シンVPS（10月17日掲載、10月18日完了） | お客様アカウント収容全ホストで、10月18日02:00頃〜08:00頃に40〜80分程度のサーバー停止を伴うシステムメンテナンスを実施、完了 [69] | 告知に本CVEやセキュリティの記載はなく、本CVEとの関係は未確認（※）。時期が近いことだけで関連付けない | | XServer VPS（10月18日の全収容ホストメンテナンス） | 告知ページは10月21日時点で取得できない（HTTP 503）。同社サイトは10月21日16:00から「予防的な安全対策」として公式サイト・管理画面・新規申し込み等を一時停止中で、「弊社システムで使用しているソフトウェアについて、セキュリティ上の問題（脆弱性）の詳細と修正版が本日公表される予定」「不正アクセスの発生に伴うものではない」「お客様のご利用サーバーへの影響はない」と説明（最終更新10月21日16:20）[70] | 10月21日の停止は「本日公表予定」の別の脆弱性を理由としており、10月15日公開の本CVEとは別件と読む。10月18日のVPSメンテナンスの内容・本CVEとの関係は未確認（※） | | お名前.com デスクトップクラウド（10月21日04:00時点） | 10月20日に第三者による不正アクセスと不正プログラムの設置を確認。全プランが対象で、影響の可能性があるサーバーは26,739台。保存情報が閲覧された可能性があり、個人情報の漏えい・悪用は現時点で未確認。利用者に認証情報の変更・使い回しの変更・フィッシング警戒を依頼 [71] | 原因・脆弱性は特定されておらず、本CVEへの言及もない。 本CVEの悪用事例、VPS（KVM）の受付停止理由、Red Hatの悪用評価の根拠のいずれにも転用しない。26,739台は「影響の可能性」であり侵害確認件数ではない | 海外クラウド・VPS：完了した範囲と作業中の範囲 | 事業者・最新告知の時刻 | ホスト側の状態 | 利用者への影響・留保 | |---|---|---| | Akamai／Linode Compute（10月17日05:07 UTC＝14:07 JST） | Computeハイパーバイザへの修正適用完了を公表（「Akamai has completed patching Compute hypervisors」）。同社プラットフォーム上で悪用の証拠は確認していないとする [50] | 利用者管理のゲストOSのカーネル更新を別途推奨。特にコンテナ・ネストした仮想化で低信頼コードを動かす場合を挙げる。修正版イメージは当該告知時点では準備中 | | Hostinger VPS（10月18日07:44 UTC＝16:44 JST） | 全VPSホストノードのセキュリティ更新完了、通常稼働、Resolvedを公表。10月16日11:20 UTCからバッチ単位で適用 [51] | メンテナンス中にVPSを一時再起動。停止したままのアプリケーションがあれば起動し、ブート時の自動起動設定を確認するよう案内。VPS以外の製品へ完了範囲を拡張しない | | UpCloud（記事本文の表記は10月20日10:41 UTC＝19:41 JST最終更新） | Cloud Server・Private Cloud・GPU Serverを影響対象とし、必要な対策をプラットフォーム全体へ展開中と説明（「actively deploying these updates」）。完了とは記載なし（※）。記事にはどの部分がいつ変更されたかの表示がない [52] | 大半の顧客に目立った影響はない見込み。GPU Serverは同社構成ではライブマイグレーション不可で、停止・再起動により約30〜60分の停止を予定。GPU・Private Cloud利用者へは個別連絡。ワークロードが中断する可能性もわずかにあると記載 | | dataforest／旧PHP-Friends／Avoro（10月20日22:19 CEST＝21日05:19 JST） | 全ホストの再起動完了・メンテナンス完了を公表（ステータス表示は Verifying、Resolved ではない）。経過：dataforestの全クラウドノード（停止約5〜10分）と旧PHP-Friendsの全ホストは10月19日01:15 CESTに完了。Avoroは想定外の事前準備で期間を2日延長し、10月19日17:47 CESTに再起動したノード epyc9374f-2 で予期せぬ問題（ts12.avoro.euとAvoro顧客エリアのVPS管理機能にも影響、18:17に解消、停止合計30分）、10月20日にも epyc9754-4（14:32再起動、14:55復帰）・vps-017（15:15再起動、15:35復帰）で想定より長い再起動があった [53] | 完了告知は「The reboots were necessary for the security patch to take effect. We completed the rollout before a public exploit was available.」とするが、公開エクスプロイトの有無は同社の認識であり、本稿で独立に確認したものではない。ノード単位の障害はセキュリティメンテナンスに関連する障害の報告で、本件の悪用による停止ではない。uptimeで再起動済みかを確認する案内。Verifying の数時間後に告知を閉じるとしており、閉鎖後の状態は未確認（※） | | Hetzner Cloud Server（開始日時欄 10月16日06:00 UTC＝15:00 JST） | ステータスはInvestigating。公表直後に暫定的な緩和策を開発し、「it detects the attack vector at the system level」（攻撃経路をシステムレベルで検出）とし、現時点の知見では攻撃を効果的に無効化すると説明。今後数時間〜数日で追加の対策を実施予定 [60] | 暫定策の具体的な実装・適用範囲、恒久修正の完了は記載がなく未確認（※）。Investigating表示の継続を、未対応とも対応済みとも読まない | これらの対応がすべて同日に開始・完了したという意味ではありません。事業者の「ホスト修正完了」と、利用者のゲストOS・自己管理KVM・コンテナ基盤の修正状況は別です。メンテナンスの実施・完了と、本CVEの修正の実施・完了も別で、告知が本CVEを明記しない作業はそのまま本CVE対応とは扱いません。「同社で悪用を確認していない」という公表を、世界全体の悪用の不存在へ一般化しません。告知が見つからないことは、未対応・対応済みのどちらの証拠にもなりません。本稿は公開資料の調査であり、契約者向けメール、サポートチケット、非公開の適用記録まで確認したものではありません [50][51][52][53][60]。 6. 公共部門・自治体の観点 この節は、前節までの公開資料を公共部門の運用へ当てはめた筆者の分析です。原典が自治体やガバメントクラウドの個別構成で攻撃成立を確認したという意味ではありません。 - ガバメントクラウド利用者：CSP管理の物理ホストを利用者が更新することはできません。ただし「打てる手がない」わけではなく、対象サービス・経路の確認、CSPへの照会（AWSは対象管理サービスの非影響判定、さくらのクラウドは10月20日に新規プロジェクト作成を再開しつつ順次メンテナンス、Google Cloud／OCIの個別判定は※）、委託先が構築した自己管理Linuxホスト（bare-metal上のKVM等）の更新確認、不審ワークロードの停止などは管理範囲に応じて可能です。誰がそのLinuxを管理しているかを先に特定します [10][17]。 - 「クラウドだから物理分離相当」への含意：本件は、特定の共有Linuxホスト構成でゲスト→ホストの隔離境界が破られた報告として説明資料に使えます。ただし、別テナントの顧客データの取得まで実証されたという意味ではなく、全クラウドの分離機構が同じ欠陥で破られる、ガバメントクラウドで同じ実証がされた、という事実にもなりません。分離方式の一般論と、本件による個別サービスの影響確認を分けて書きます [13][15]。 - 自治体・ベンダーのオンプレKVM基盤：仮に三層分離の各層をProxmox／libvirt等で仮想化していたり、Linux KVMベースのアプライアンスを利用していたりする場合は、その名称だけで脆弱性を確定せず、Linuxの修正状況と入力・到達経路を確認します。影響する構成には、ディストリ／ベンダーの修正済みビルドを適用します。信頼レベルの異なるVM（インターネット接続系とLGWAN系、外部委託先VMと庁内VM等）が影響する同一Linuxホストを共有している場合は、境界横断リスクを優先して検討します。原典は自治体の三層分離構成を調査・実証していないため、これは筆者の当てはめです [3][2]。 - AIエージェント実行基盤：外向き通信を遮断していても、その前段のTAP／ホスト処理へ攻撃入力が到達するならリスクは残ります。一方、仮想NICがなく代替のTUN／AF_PACKET入力もない構成まで、この実証経路で危険とはいえません。「ネットワーク遮断」がどの層で実装されているかを明示して評価します。別のネットワーク分離回避事例を、本件の成立条件を満たす証拠として代用しません [2][15]。 - 利用制限・メンテナンスへの実務対応（筆者の分析）：既存業務が稼働していても、新規契約・プロジェクト作成・増設・追加VMの可否は事業者ごとに異なるため、移行計画や復旧時の代替環境確保への影響を確認します。メンテナンス通知がCSPから受託事業者だけに届く構成では、自治体の情報政策担当・運用担当・利用部門へ日時と停止影響を伝える責任者を決めておきます。これは公表された制限・通知方針を運用へ当てはめた提案であり、個別自治体の停止や移行遅延を確認した事実ではありません [16][48][52]。 - 「受付再開」と「修正完了」を分けて管理する（筆者の分析）：さくらのクラウドの新規プロジェクト作成再開（10月20日）やABLENETの「新規注文を収容するホストは対策済み」は、新規利用の再開や新規用ホストの状態を示すもので、既存ホストを含む全体の修正完了ではありません。運用上は「受付再開」「新規用ホストの対策」「既存ホストの対策」「全体完了」を別の確認項目として台帳に持ち、事業者の公表と筆者の提案を混同しないようにします [16][49]。同様に、RHELやCOSのようなOS・イメージ側の修正提供と、クラウド管理基盤の適用完了も別項目です [72][75]。 - 関連が未確認の事案を本件に結び付けない（筆者の分析）：時期の近いメンテナンスや、原因未特定の不正アクセス事案（お名前.comデスクトップクラウド等）を、本CVEの対応や悪用事例として扱わないようにします。庁内や議会への説明では「本CVEの対応として公表されたもの」「時期が近いが関係未確認のもの」「別件として公表されたもの」を分けて提示します [69][70][71]。 7. 取るべき対応 1. 影響するLinuxに、修正を含むサポート対象のカーネル／ベンダービルドを適用する。 ホスト側の脆弱性は、ゲストのカーネルだけを更新しても修正されません。一方、ゲスト内Linux自身に入力経路がある場合は、そのLinuxの更新も別途判断します。個別コミットだけを無検証で取り込むのではなく、ディストリ／ベンダーが検証した更新を優先し、必要な再起動と動作確認を行います。CVEの確定待ちや後続の入力検証案を理由に、配布済み修正の適用を延期しません [3][10]。 2. 配布経路とサポート範囲を確認する。 テスト版の存在だけで本番適用可と判断せず、検証・切戻し・保守条件を確認します。AlmaLinuxの almalinux-testing、Proxmoxの pve-no-subscription、KernelCareのmain feed／testingは、それぞれ性質が異なります。main feedで提供済みのパッチも、対象ビルド・契約・適用結果を確認します。本稿はリポジトリの無条件な切替や、テストフィードの本番適用を推奨するものではありません。サポート終了系列では、修正を待つだけでなく、サポート対象の構成への移行も検討します [34][35][38]。 3. 「インストール済み」と「実行中」を区別する。 ベンダーの修正済みビルド（Amazon Linuxのようにupstreamより小さいベース版数の場合がある）と、現在稼働しているカーネル／ライブパッチ状態を照合します [10][2]。 4. 後続の入口検証強化を監視する。 採用・配布された修正の内容に応じて追加更新を判断します（必ず追加更新が必要になると現時点で断定はしません）[3][8]。 5. 当面の露出低減は、構成別の補助策として検討する。 以下は公開された処理経路からの技術的検討であり、ベンダーが保証した共通の回避策ではありません。AWSも本件の回避策を示していません。 - ゲスト由来トラフィックがNFQUEUE／xfrm／CHECKSUMターゲットの該当する完成処理を通らないようにできれば、その経路の露出は減らせます。ただし、モジュールの有無だけでは判断できず、他の完成処理が残らないかを確認します [3]。 - ホストでのIPv4フラグメント処理を実際に避けられる経路は、その処理への露出低減になります。ただしMTU／MSSの調整だけで、悪意あるゲストが送る全パケットについて到達を防げるとは限らず、他の完成経路への対策にはなりません [3][15]。 - チェックサムオフロードの無効化は、ゲスト側設定、virtio機能交渉、TAP側設定、物理NIC側設定で意味が異なります。TUNの実装注記にはゲストの交渉済み機能を把握していない旨があり、出力デバイスが処理しないチェックサムはソフトウェア処理へ回る場合があります。物理NIC等のスイッチを切ることと、不正な入力メタデータを拒否することは同義ではありません。 VMM・バックエンド・カーネルの版と実装を確認せず、「オフロードを無効にすれば安全」とは結論しません [26][29]。CloudLinuxの公式記事も、オフロード無効化や非特権user namespaceの無効化を挙げつつ、「Partial workarounds exist. None has been tested against this bug yet」として未検証と明記しています。これを検証済みの共通回避策として転記しません [46]。 構成変更による通信断・性能低下等も評価し、修正適用の代替として扱いません [10]。 6. 多テナント基盤では可用性への影響も優先して評価する。 攻撃入力を処理するLinuxホストが停止すれば、その上のVM群に停止・利用不能が及びえます。重要業務への影響、異なる信頼レベルのワークロードの同居、更新時の退避・復旧手順を確認します。ただし、DoSが必ず情報漏えいやコード実行に先行するという予測ではなく、機密性・完全性の評価を省略する理由にもなりません [13][2]。 7. 利用制限と個別メンテナンス通知を運用計画に反映する（筆者の提案）。新規契約・プロジェクト・追加VM・スケールアップのどの操作が制限されるか、CSP／委託先からの登録メールを誰が確認するか、再起動時のアプリケーション復旧・自動起動・切戻しを誰が担当するかを確認します。公開告知で停止時間が未確定なら、個別通知で確定させます。作業終了の公表だけでなく、管理範囲に応じてCSPの完了通知、実行中の修正済みビルド、または適用済みライブパッチの証跡を記録します [16][48][50][51][52][55]。 CSP・委託先への確認票（例）： | 確認する内容 | 回答で明確にする点 | |---|---| | 影響判定の根拠と範囲 | どのサービス・ホスト群・管理階層が、非影響／修正済み／対応中なのか | | メンテナンスと通知 | 作業日時、停止・性能影響、通知の宛先、利用者の事前／事後作業 | | 修正の証跡 | 対象ビルドまたはライブパッチ、適用済み状態、残る未適用範囲と予定 | | 受付の再開条件 | 停止している操作の単位、既存契約内の追加作成可否、再開の確認方法。受付再開が全ホストの修正完了を意味するかどうか | 8. 記事化・資料化する場合：欠陥の所在は「Linuxカーネルのネットワークスタック」、実証された経路の一つは「ゲスト→ホスト境界侵害」と分けて書きます。CVSSのAV:L・PR:Nは、CNAが説明するmicroVM経路の前提とともに示します。研究者所有環境の実証を、すべての製品やベンダー本番環境での攻撃成立に拡張しません。悪用に関するベンダー記載、CISAのKEVカタログ、SSVC評価も、評価主体と時点を分けて示します [2][15][37][44]。 8. 開示・対応タイムライン 日付は原資料の表記を基本とします。時差が重要な項目にはUTC／PDT／JSTを併記しました。非公開の連絡については研究者の開示履歴として扱い、当時のメール原本を独立確認したものではありません。 | 日付（2026年） | 出来事 | 出典 | |---|---|---| | 8月18日 | Vercelが100万ドルのSandboxチャレンジを公表 | Vercel公式 [14] | | 8月20日 | 研究者が初期のホストメモリ漏えい報告を提出 | 研究者の開示履歴 [15] | | 9月4日 | カーネルセキュリティ窓口・netdevメンテナへ根本原因と候補パッチを非公開報告 | 研究者の開示履歴 [15] | | 9月7日 | Michael S. Tsirkinが再現を確認、候補パッチを受領 | 研究者の開示履歴 [15] | | 9月19〜22日 | netdevで公開パッチ投稿・改訂、レビュー範囲が拡大 | netdev [15][7] | | 9月25日 | CVE-2026-99999予約 | CVEレコード [2] | | 10月7日 | Tsirkinの改訂版ガード投稿。Willem de Bruijnの入口側検証案も投稿（翌8日に再提出要求。各案の最新状態は第4節の留保を参照） | netdev [15][31] | | 10月8日 | net.gitに受理（patchwork bot）。Linus宛てpull要求送付 | netdev／LKML [6][15] | | 10月9日 | mainlineにマージ（af32da41、net-7.3-rc7） | torvalds/linux [5] | | 10月14日 | Vercelがチャレンジ結果を公表 | Vercel公式 [13] | | 10月15日 | CVE公開（12:19 UTC＝21:19 JST）。修正を含むstableリリース（6.1.190・7.2.11の変更履歴で日付を確認）。AWS告知（10:30 PDT＝10月16日02:30 JST）。入口側修正のv2系列がnet-nextに投稿（受理・収録は※） | CVE／kernel.org／AWS／netdev [2][9][10][8] | | 10月16日 | さくらインターネットが全社・クラウド・VPS・レンタルサーバ等の対応告知を公表。サービスごとの新規受付・機能制限を案内。ABLENET VPSが影響確認中の告知 | さくら公式・ABLENET [16][17][40][41][49] | | 10月16日（公表日） | Oracle LinuxがUEK R6／R7／R8向けの修正エラッタ（ELSA-2026-500397／500398／500399）を公表。OCI管理基盤への適用完了とは別 | Oracle公式 [54] | | 10月16日 06:00 UTC（15:00 JST） | Hetzner Cloud Serverのインシデント開始日時欄。Investigating、暫定緩和策を説明 | Hetzner公式 [60] | | 10月16日 11:20 UTC（20:20 JST） | HostingerがVPSホストへの緊急メンテナンス開始を告知（バッチ単位で適用、VPSは再起動） | Hostinger公式 [51] | | 10月16日 13:39 UTC（22:39 JST） | DebianがDSA-6568-1を告知。trixie向け linux 6.12.113-1 に本CVEの修正を収録 | Debian公式 [33] | | 10月16日 15:49 UTC（17日00:49 JST） | CVEレコード更新。CISAのSSVC追加評価（Exploitation: none等）を掲載 | CVEレコード [2] | | 10月16日 20:17 UTC（17日05:17 JST） | AlmaLinuxが8／9／10向け修正カーネルのテスト提供（almalinux-testing）を告知 | AlmaLinux公式 [34] | | 10月16日 17:34 UTC（17日02:34 JST） | CloudLinux公式ステータスがKernelCareの配布先を更新。AlmaLinux 9／CloudLinux 9用 K20261016_0002 はmain feed、RHEL 9／Oracle Linux 9／Rocky Linux 9の掲載セットはtesting | CloudLinux公式 [55] | | 10月17日 05:07 UTC（14:07 JST） | Akamai／LinodeがComputeハイパーバイザの修正適用完了を公表。ゲストOS更新は別途推奨 | Akamai公式 [50] | | 10月17日（告知一覧の掲載日） | DebianがDLA-4841-1を掲載。bookworm向け linux 6.1.190-1 に本CVEの修正を収録。告知メールの正確な送信時刻は未確認（※） | Debian公式 [11][45] | | 10月17日 11:14 UTC（20:14 JST） | CVEレコードのLinux CNAコンテナ更新（修正版一覧・参照に変更なし） | CVEレコード [2] | | 10月17日 20:07 UTC（18日05:07 JST） | UpCloudが記事を最終更新（本文表記）。対象サービスへの対策展開中、GPU Serverの停止・再起動影響を案内。更新時刻を作業完了時刻とは扱わない | UpCloud公式 [52] | | 10月18日（告知日表記） | 使えるねっとが対象VPS（クラウドVPS VM／VM＋Plesk／FX専用VPS）の新規申し込み受付を停止（既存契約者の追加申し込みも対象） | 使えるねっと公式 [59] | | 10月18日 02:00〜08:00頃 JST | シンVPSが全収容ホストで40〜80分の停止を伴うシステムメンテナンスを実施・完了（本CVEとの関係は未確認※） | シンVPS公式 [69] | | 10月18日（リリース日表記） | Linux 7.3正式版を公開。10月9日のマージ・7.3-rc7への修正収録とは別の履歴 | kernel.org [56] | | 10月18日 07:44 UTC（16:44 JST） | Hostingerが全VPSホストノードの更新完了・通常稼働・Resolvedを公表 | Hostinger公式 [51] | | 10月19日 01:15 CEST（08:15 JST） | dataforest／旧PHP-Friendsはパッチ適用・再起動完了、Avoroは追加準備により再起動未実施・作業期間を2日延長と更新 | dataforest公式 [53] | | 10月19日（告知日表記） | さくらのクラウドが順次メンテナンス・実施日の約1週間前の通知方針を追記（新規プロジェクト作成停止は継続）。ConoHa VPSが新規申し込み受付停止を告知（既存契約者のVPS追加は可能）。Google Container-Optimized OS 129／125／121のリリースノートに本CVE修正イメージを掲載 | さくら公式・ConoHa公式・Google [16][48][75] | | 10月19日 16:00 JST | お名前.com VPS（KVM）が全プランの新規申し込み受付を一時停止 | お名前.com公式 [66] | | 10月19日 18:00 JST | KAGOYAがCLOUD VPS・MAIL・レンタルサーバー等の新規申し込み受付を一時停止 | KAGOYA公式 [65] | | 10月19日 09:27 UTC（18:27 JST） | CVEレコードのLinux CNAコンテナ更新。mainline修正版の表記が 7.3-rc7 から 7.3 に。CVSS・stable修正版・参照は不変 | CVEレコード [2] | | 10月19日 12:03 UTC（21:03 JST） | Tsirkinが [PATCH net v3 0/8] more virtio-net csum hardening（8本）を投稿。UML部分はコンパイル確認のみと明記 | lkml [61] | | 10月19日 17:47〜18:17 CEST（20日00:47〜01:17 JST） | Avoroノード epyc9374f-2 の再起動後に予期せぬ問題が発生、18:17に解消（停止合計30分）。18:21 CESTに復旧を公表 | dataforest公式 [53] | | 10月19日 13:26 米東部時間（lkml.iu.edu表示） | Chris Argesがv3系列に対しKASANエラーが出なくなったとして Tested-by を返信（UML関連パッチは未テスト）。受理通知ではない | lkml [62] | | 10月19日 21:19 UTC（20日06:19 JST） | CVEレコードのCISA ADPコンテナ更新（レコード全体の dateUpdated も同時刻）。CWE-20の追加のみで、SSVC評価は10月16日15:49 UTCのまま | CVEレコード [2] | | 10月19日 23:56 CEST（20日06:56 JST） | dataforestが、Avoroの残りのホストの再起動は継続中・メンテナンスは未完了と更新 | dataforest公式 [53] | | 10月20日（告知日表記） | さくらのクラウドが新規プロジェクト作成を再開（各機能は通常どおり利用可、順次メンテナンスと1週間前通知の方針は維持）。ABLENET VPSが「新規注文を収容するホストは対策済み、既存ホストは順次」と更新（新規申し込み停止の予定なし）。Red HatがRHEL 9／9.4／10.0 EUS向けの3エラッタ（RHSA-2026:86033／86089／85979）を公表 | さくら公式・ABLENET公式・Red Hat [16][49][72][73][74] | | 10月20日 10:41 UTC（19:41 JST） | UpCloudが記事を最終更新（本文表記）。対策は引き続き展開中 | UpCloud公式 [52] | | 10月20日 19:00 UTC（21日04:00 JST） | CISA KEVカタログが2026.10.20版に更新（6件追加、本CVEは含まれない） | CISA [44] | | 10月20日 19:15 JST | さくらインターネットが全社告知に追記（18:30時点の情報）。クラウドの再開、VPS告知の表現修正（影響範囲は変更なし）を案内。対象サービスにさくらのクラウド・VPS・レンタルサーバ・高火力DOK・高火力VRTを列挙 | さくら公式 [17] | | 10月20日 21:00〜21日03:00 JST | さくらのVPSが一部ホストのソフトウェアメンテナンス39837を実施、21日02:03に完了（告知に本CVEの記載なし） | さくら公式 [68] | | 10月20日 22:19 CEST（21日05:19 JST） | dataforestが全ホスト（Avoro含む）の再起動完了・メンテナンス完了を公表（表示は Verifying） | dataforest公式 [53] | | 10月20日 22:32 米東部時間（lkml.iu.edu表示） | Jakub Kicinskiがv3系列にビルド警告2点を指摘（受理・却下の判断なし） | lkml [76] | | 10月21日 03:55 米東部時間（lkml.iu.edu表示） | Tsirkinが [PATCH net v4 0/7]（7本）を投稿。UML部分はコンパイル確認のみ。受理・収録は未確認 | lkml [77] | | 10月21日 04:00 JST時点 | お名前.comがデスクトップクラウドの不正アクセス（10月20日確認、影響の可能性26,739台）を公表。原因未特定、本CVEへの言及なし（別件） | お名前.com公式 [71] | | 10月21日（告知日表記） | WebARENA（Indigo／IndigoPro／SuitePRO V4／Wasabi）が新規申し込みを一時停止（既存インスタンスの利用・追加は可） | WebARENA公式 [64] | | 10月21日 15:00〜22日18:00 JST | さくらのVPSが全リージョンで緊急メンテナンス39864を実施中（ホスト順次再起動、1VPSあたり約1時間停止。告知に本CVEの記載なし） | さくら公式 [67] | | 10月21日 16:00 JST | XServerが「本日公表予定」の別の脆弱性への予防措置として公式サイト・管理画面・新規申し込みを一時停止（本CVEとは別件。利用者サーバーへの影響なしと説明） | XServer公式 [70] | 9. 参照 1. CVE Program：CVE-2026-99999 — cve.org 2. CVE Program：公式レコード（JSON。公開日時・CNAのCVSS評価・修正版。全体更新10月19日21:19 UTC＝CISA ADP更新〔CWE-20追加〕／CNA更新10月19日09:27 UTC／SSVC評価時刻10月16日15:49 UTC） — raw.githubusercontent.com 3. Linux修正コミット 6785011f8b16：ipv4: validate checksum_start before completing checksum — github.com/torvalds/linux/commit/6785011f8b16abf4… 4. Fixes対象の原コミット（tun：2008年／packet：2010年） — github.com/torvalds/linux/commit/f43798c27684ab92… ／ github.com/torvalds/linux/commit/bfd5f4a3d605e0f6… 5. mainlineマージコミットとマージ通知（net-7.3-rc7） — github.com/torvalds/linux/commit/af32da41b0327b9c… ／ lkml.iu.edu 6. net.git受理通知／Linus宛てpull要求（10月8日） — lists.openwall.net ／ lists.openwall.net 7. 研究者の初期パッチ系列（v4、9月20日） — lists.openwall.net ／ lists.openwall.net ／ lists.openwall.net 8. 入口側の入力検証案・レビュー（10月15日のv2 4/7とレビュー本文は確認。10月17日分は[39]。※受理・収録状況は未確認） — lists.openwall.net ／ lists.openwall.net ／ lkml.iu.edu ／ lkml.iu.edu 9. kernel.org：修正を含むリリースの変更履歴（6.1.190／7.2.11） — kernel.org ／ kernel.org 10. AWS Security Bulletin 2026-137-AWS — aws.amazon.com 11. Debian Security Tracker：CVE-2026-99999 — security-tracker.debian.org 12. Ubuntu Security：CVE-2026-99999 — ubuntu.com 13. Vercel：Findings from the $1M Vercel Sandbox challenge（10月14日） — vercel.com 14. Vercel：チャレンジ募集・構成・脅威モデル（8月18日） — vercel.com 15. pwn.ai：PwnEscape: Guest-to-Host KVM Escape（研究者の実証報告・予測） — pwn.ai 16. さくらのクラウド：CVE-2026-99999への対応状況（10月16日初回／10月19日更新でメンテナンス方針を追記／10月20日更新で新規プロジェクト作成の再開） — cloud.sakura.ad.jp 17. さくらインターネット：全社告知（10月16日17:00時点。10月20日19:15追記、18:30時点の情報） — sakura.ad.jp 18. AWS：The Security Design of the AWS Nitro System — docs.aws.amazon.com 19. Firecracker：設計文書 — github.com/firecracker-microvm/firecracker/blob/m… 20. Google Cloud：Compute Engineのnested virtualizationとKVMベース基盤 — docs.cloud.google.com 21. Oracle：Virtualization（KVMとOCIに関する公表） — oracle.com 22. Microsoft：Hypervisor security on the Azure fleet — learn.microsoft.com 23. gVisor：Networking Guide — gvisor.dev 24. Kata Containers：Architecture — github.com/kata-containers/kata-containers/blob/m… 25. Open vSwitch：DPDK vHost User Ports — docs.openvswitch.org 26. Linuxカーネル文書：Checksum Offloads — docs.kernel.org 27. Linuxカーネル文書：Universal TUN/TAP device driver — docs.kernel.org 28. Linux man-pages：packet(7) — man7.org 29. Linux v7.3-rc7：drivers/net/tun_vnet.h（TUNとゲスト機能交渉に関する実装・注記） — raw.githubusercontent.com 30. Linux CNAの告知（linux-cve-announce、10月15日。レコード本体は[2]） — lists.openwall.net 31. Michael S. Tsirkinの修正投稿（netdev、10月7日） — lists.openwall.net 32. 初期報道（歴史的な説明・個別報奨額の報道に限定。現在の修正状況は一次資料を優先） — techzine.eu ／ webhosting.today 33. Debian：DSA-6568-1の告知メールとトラッカー（10月16日13:39 UTC） — lists.debian.org ／ security-tracker.debian.org 34. AlmaLinux：PwnEscape — Patched kernels available in testing（初回公開10月16日20:17 UTC） — almalinux.org 35. Proxmox公式フォーラム：投稿#2はスタッフの修正ビルド・配布先確認、投稿#4はenterpriseに関する利用者（Subscriber）報告 — forum.proxmox.com 36. SUSE：CVE-2026-99999（CVSS v3.1／v4.0・Pending・製品別評価） — suse.com 37. Red Hat：CVE-2026-99999（CVSS v3.1暫定評価・Statementの悪用に関する記載。記載追加日時・具体的な攻撃事例は未確認） — access.redhat.com 38. TuxCare：PwnEscape / KernelCare（10月16日時点の記事。テストフィード案内と「未提供」の明記。※本番提供完了は未確認） — tuxcare.com 39. netdev：10月17日の入口検証に関する議論（追跡用。※本文は未取得、採用・収録状態は未確認） — lists.openwall.net 40. さくらのVPS：Linuxカーネル脆弱性への対応状況（10月16日付、同日18:10追記） — vps.sakura.ad.jp 41. さくら：レンタルサーバ・マネージドサーバの新規申し込み受付停止（メール専用プランを含む、10月16日付） — help.sakura.ad.jp 42. Google Cloud：Security bulletins（本CVEの個別影響判定は未確認。追跡用） — docs.cloud.google.com 43. Oracle：Security Alerts（本CVEのOCIサービス別影響判定は未確認。追跡用） — oracle.com 44. CISA公式KEVカタログ（JSON。10月21日時点で catalogVersion: 2026.10.20、dateReleased 10月20日19:00 UTC、1,754件。この版で本CVEの収載を確認できなかった） — raw.githubusercontent.com 45. Debian：DLA-4841-1とLTS告知一覧（bookwormの修正。告知一覧の掲載日は10月17日） — security-tracker.debian.org ／ debian.org 46. CloudLinux：CVE-2026-99999 Guest-to-Host Escape（10月16日付。ライブパッチの状態説明が併存し、緩和策には未検証注記） — blog.cloudlinux.com 47. netdev：2026年10月17日の日次一覧（selftest RFC案と返信の掲載。※個別レビュー結論は未確認） — lists.openwall.net 48. ConoHa VPS：新規お申し込みの一時受付停止について（10月19日付） — vps.conoha.jp 49. ABLENET VPS：ニュース（10月16日付の影響確認告知／10月20日付で新規収容ホスト対策済み・既存ホスト順次と更新） — ablenet.jp 50. Akamai／Linode：(PwnEscape) Guest-to-Host KVM Escape [CVE-2026-99999]（ステータスページ。10月17日05:07 UTCにComputeハイパーバイザの修正完了） — status.linode.com 51. Hostinger：VPS Emergency maintenance（ステータスページ。10月18日07:44 UTCにResolved） — statuspage.hostinger.com 52. UpCloud：PwnEscape Linux kernel vulnerability – UpCloud's response（本文表記は10月20日10:41 UTC最終更新。対策展開中） — upcloud.com 53. dataforest：Critical Security Update on Virtualization Infrastructure（ステータスページ。10月19日01:15 CESTにdataforest／旧PHP-Friends完了・Avoro延長、同日18:09〜18:21 CESTにAvoroノード障害と復旧、10月20日22:19 CESTに全ホスト完了〔Verifying〕） — status.dataforest.net 54. Oracle Linux：CVE-2026-99999とUEK R6／R7／R8の修正エラッタ（10月16日公表） — linux.oracle.com ／ linux.oracle.com ／ linux.oracle.com ／ linux.oracle.com 55. CloudLinux公式ステータス：PwnEscape (CVE-2026-99999)（KernelCareパッチセット別の配布先。10月16日17:34 UTC更新） — cloudlinux.statuspage.io 56. kernel.org：リリース一覧（Linux 7.3正式版のリリース日は10月18日、stable各系列の修正版は10月15日と掲載） — kernel.org 57. Google Cloud：Compute Engine security bulletins（本CVEの個別影響判定は未確認。追跡用） — docs.cloud.google.com 58. Google Cloud：GKE security bulletins（本CVEの個別影響判定は未確認。追跡用） — docs.cloud.google.com 59. 使えるねっと：Linuxカーネル脆弱性（CVE-2026-99999）に伴うVPS新規申し込み受付停止（10月18日付。既存契約者の追加申し込みも対象） — tsukaeru.net 60. Hetzner Status：CVE-2026-99999 (PwnEscape)（Cloud Server。Investigating、暫定緩和策の説明。開始日時欄10月16日06:00 UTC） — status.hetzner.com 61. lkml.iu.edu：[PATCH net v3 0/8] more virtio-net csum hardening（Michael S. Tsirkin、10月19日。カバーレター） — lkml.iu.edu 62. lkml.iu.edu：Re: [PATCH net v3 0/8] more virtio-net csum hardening（Chris Arges、10月19日。Tested-by、UML関連は未テスト） — lkml.iu.edu 63. ConoHa VPS：新規お申し込み停止中の案内画面（10月21日時点で停止表示を確認） — vps.conoha.jp 64. WebARENA（NTTPC）：Linuxカーネルの脆弱性（CVE-2026-99999）に伴う新規お申し込みの一時停止（10月21日付。Indigo／IndigoPro／SuitePRO V4／Wasabi。既存インスタンスの利用・追加は可） — web.arena.ne.jp 65. KAGOYA：Linuxカーネルの脆弱性（CVE-2026-99999）に伴う新規お申し込み受付の一時停止（10月19日18:00から） — kagoya.jp 66. お名前.com：VPS（KVM）新規お申し込み受付の一時停止（10月19日16:00から、全プラン） — onamae.com 67. さくらのVPS：[緊急]東京・大阪・石狩リージョン ソフトウェアメンテナンス（メンテナンス番号39864、10月21日15:00〜22日18:00、1VPSあたり約1時間停止。本CVEの記載なし） — support.sakura.ad.jp 68. さくらのVPS：東京・大阪・石狩リージョンの一部 ソフトウェアメンテナンス（メンテナンス番号39837、10月20日21:00〜21日03:00、21日02:03完了。本CVEの記載なし） — support.sakura.ad.jp 69. シンVPS：お客様アカウント収容全ホストのシステムメンテナンス（10月17日掲載、10月18日完了、40〜80分停止。本CVEとの関係は未確認） — shin-vps.jp 70. XServer VPS：10月18日のメンテナンス告知（10月21日時点でHTTP 503。同社サイトは10月21日16:00から別の脆弱性への予防措置で一時停止中、最終更新同日16:20） — vps.xserver.ne.jp 71. お名前.com：デスクトップクラウドへの不正アクセスについて（10月21日04:00時点。原因未特定、本CVEへの言及なし。別件） — onamae.com 72. Red Hat：RHSA-2026:86033 Important: kernel security update（RHEL 9、10月20日。kernel-5.14.0-687.59.1.el9_8） — access.redhat.com 73. Red Hat：RHSA-2026:86089 Important: kernel security update（RHEL 9.4 AUS／Update Services for SAP Solutions／4 years of updates／Extended Life Cycle、10月20日。kernel-5.14.0-427.157.1.el9_4） — access.redhat.com 74. Red Hat：RHSA-2026:85979 Important: kernel security update（RHEL 10.0 EUS／4 years of updates、10月20日。kernel-6.12.0-55.112.1.el10_0） — access.redhat.com 75. Google：Container-Optimized OS リリースノート m129／m125／m121（10月19日付。cos-129-19506-549-22／cos-125-19216-739-16／cos-121-18867-638-13 に「Fixed CVE-2026-99999 in the Linux kernel」） — docs.cloud.google.com ／ docs.cloud.google.com ／ docs.cloud.google.com 76. lkml.iu.edu：Re: [PATCH net v3 0/8] more virtio-net csum hardening（Jakub Kicinski、10月20日。ビルド警告2点の指摘） — lkml.iu.edu 77. lkml.iu.edu：[PATCH net v4 0/7] more virtio-net csum hardening（Michael S. Tsirkin、10月21日。カバーレター） — lkml.iu.edu --- 本稿は筆者個人の分析であり、所属組織や各事業者の公式見解ではありません。基準日：2026年10月21日。※印は本稿で確認できなかった事項。公表情報と実行中カーネル・個別構成は異なるため、適用判断時には原典と自環境を再確認してください。

Sandbox Claude Code and Codex 2026: Docker, gVisor, microVM For one developer running Claude Code or Codex CLI unattended, a hardened Docker container with default-deny egress covers most of the real risk, and gVisor or a microVM only pays off when you run code you do not control. Docker shares the host kernel, gVisor swaps it for a user-space kernel written in Go, and a microVM such as Firecracker gives each workload its own guest kernel behind KVM. The part people skip is egress: a perfectly isolated container that can reach any host still leaks every file it can read. Both Anthropic and OpenAI say the same thing in their docs, and both tell you to put the permission-bypass flags inside an isolation boundary. Below: the threat model, what the bypass flags remove, one comparison table, a hardened docker run, a compose egress proxy, runsc registration, and the microVM entry points. TL;DR - The threat is a prompt-injected shell that reads credentials and sends them out. Kernel escapes are the rarer problem. - --dangerously-skip-permissions (Claude Code) and --yolo (Codex) remove the prompts. Neither adds isolation, so the container has to. - Docker hardening (non-root, read-only rootfs, --cap-drop ALL, no-new-privileges, egress allowlist) gets you most of the way. - gVisor: add it when you want a smaller host-kernel surface and your toolchain survives its syscall gaps. 62 of 352 syscalls are unsupported. - microVM: add it for multi-tenant agents, CI runners, or untrusted repos. Firecracker advertises under 125 ms boot and under 5 MiB overhead per VM. - On macOS 26 with Apple silicon, Apple's container tool runs Linux containers as lightweight VMs. The threat model for an unattended coding agent An agent that runs for an hour with no human watching has four realistic failure paths, in the order they bite: 1. Prompt-injected shell. A README, issue, web page or dependency postinstall script contains instructions. The model follows them and runs curl or npm publish with your tokens. 2. Exfiltration over egress. Anything the process can read leaves through any open port. Isolation does not help if the network is open. 3. Credential files in $HOME. ~/.ssh, ~/.aws, .env files and the agent's own login token. Anthropic's dev container page warns that with the skip flag a malicious project can exfiltrate anything reachable inside the container, including the credentials in ~/.claude[[2]](#cite-2). OpenAI's Codex docs say the same about Codex credentials[[3]](#cite-3). 4. Docker socket mounts. Mounting /var/run/docker.sock hands the agent the daemon. Docker's security page warns that API access can lead to privilege escalation and shows a bind mount of / as the example[[5]](#cite-5). A container with the socket is not a sandbox. A kernel exploit comes fifth. It matters for multi-tenant hosting, where the attacker is another customer. For a solo developer on a trusted repo it is the least likely path, which is why a hardened container often suffices. What the bypass flags actually remove Both flags remove approval prompts and, in Codex's case, the sandbox too. They are not isolation. - Claude Code: with --dangerously-skip-permissions, Claude acts without asking. Anthropic says to always run these sessions inside a container, a VM, or the sandbox runtime. The CLI refuses to start with the flag as root[[1]](#cite-1). Admins can block it with permissions.disableBypassPermissionsMode set to "disable" in managed settings[[2]](#cite-2). - Codex CLI: --dangerously-bypass-approvals-and-sandbox, alias --yolo, means no sandbox and no approvals, flagged "not recommended". The default preset is --sandbox workspace-write --ask-for-approval on-request, with network off unless you set network_access = true under [sandbox_workspace_write][[3]](#cite-3). Both vendors ship their own host-level sandboxes. Claude Code's built-in Bash sandbox is off by default, enabled with /sandbox, built on the open-source @anthropic-ai/sandbox-runtime, and uses Seatbelt on macOS and bubblewrap plus socat on Linux. It covers shell commands only. File tools, MCP servers and hooks run outside it, so Anthropic says it is not sufficient for fully unattended runs[[1]](#cite-1)[[4]](#cite-4). Codex uses Seatbelt on macOS and bwrap plus seccomp on Linux[[3]](#cite-3). These are useful layers. For unattended work, put the whole process in a container or VM and let the built-in sandbox run inside it. Anthropic notes unprivileged containers need enableWeakerNestedSandbox for that[[4]](#cite-4). For the hosted-agent angle, see [Claude Managed Agents self-hosted sandbox](/blogs/claude-managed-agents-self-hosted-sandbox-mcp-tunnels-enterprise-guide-2026). Comparison: Docker vs gVisor vs microVM vs Apple container | Option | What is isolated | Kernel | Startup | OS support | Performance cost | Egress control | Setup effort | Cost | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Docker (runc), hardened | Namespaces, cgroups, capabilities, seccomp (default profile blocks around 44 of 300+ syscalls) | Shared host kernel | No VM boot | Linux native; elsewhere via a Linux VM | Near zero | Your job: internal network plus proxy allowlist | Low | Free | | gVisor (runsc) | Syscalls handled by the Sentry, a Go user-space kernel | User-space kernel; host kernel sees far fewer calls | Small fixed per-sandbox cost, no numbers published | Linux hosts (install guide is Linux-only) | Low for CPU-bound work; high for syscall-heavy or small-file workloads | Netstack by default; --network=none; experimental proxy mode | Low to medium | Free, open source | | Firecracker microVM | Whole guest OS behind KVM | Separate guest kernel | Under 125 ms boot (vendor claim) | Linux x86_64 and aarch64 with /dev/kvm | Under 5 MiB overhead per VM (vendor claim) | Guest NIC, you filter at host or tap device | High (kernel, rootfs, networking) | Free, open source | | Kata Containers | Pod or container inside a lightweight VM | Separate guest kernel | Not stated in README | Linux with virtualization support | VM overhead, hypervisor-dependent | Kubernetes network policy on top | Medium to high | Free, open source | | Apple container | Linux containers as lightweight VMs | Separate guest kernel | Not published in README | macOS 26, Apple silicon only | VM overhead, no GPU claim made | No documented allowlist feature; use a proxy | Low | Free, Apache-2.0 | | Docker Sandboxes | MicroVM with its own Docker daemon and workspace sync | Separate guest kernel | Not stated | Per Anthropic: any host with it installed | VM overhead | Network policies in its Security guide | Low | Free standalone product per Anthropic; admin policy is a paid tier | Docker hardening that gets you most of the way This is the baseline. Every flag below is documented in Docker's docker run reference[[6]](#cite-6). Run the container as a non-root user, because Claude Code requires that for the skip flag anyway. docker run --rm -it \ --user 1000:1000 \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=512m \ --tmpfs /home/agent/.cache:rw,nosuid,size=1g \ --cap-drop ALL \ --security-opt no-new-privileges \ --pids-limit 512 \ --memory 4g \ --network agent_net \ -e HTTPS_PROXY=http://proxy:3128 \ -e HTTP_PROXY=http://proxy:3128 \ -v "$PWD":/work \ -w /work \ my-agent-image claude What each line buys you: --read-only stops the agent persisting malware or editing system files. --cap-drop ALL removes every Linux capability; Docker's default is already an allowlist, and dropping all is stricter[[5]](#cite-5). no-new-privileges blocks setuid escalation. The default seccomp profile stays on unless you disable it, and you can swap in your own with --security-opt seccomp=/path/profile.json[[7]](#cite-7). Mount only the project directory. Never mount ~/.ssh, cloud credential files or the Docker socket. Pass a repo-scoped, short-lived token as an environment variable instead. The remaining gap is the network. Put the agent on an internal network with no route out, and attach a proxy to both that network and a normal one: services: agent: image: my-agent-image user: "1000:1000" read_only: true cap_drop: [ALL] security_opt: ["no-new-privileges:true"] pids_limit: 512 mem_limit: 4g tmpfs: ["/tmp:rw,noexec,nosuid,size=512m"] environment: HTTPS_PROXY: http://proxy:3128 HTTP_PROXY: http://proxy:3128 volumes: ["./:/work"] working_dir: /work networks: [agent_net] proxy: image: ubuntu/squid volumes: - ./squid.conf:/etc/squid/squid.conf:ro - ./allowed-domains.txt:/etc/squid/allowed-domains.txt:ro networks: [agent_net, egress] networks: agent_net: internal: true egress: {} In squid.conf, the allowlist is three lines: acl allowed dstdomain "/etc/squid/allowed-domains.txt", http_access allow allowed, http_access deny all. Start the domain file with api.anthropic.com or api.openai.com, plus your package registry, and add hosts only when a build fails and you agree it should succeed. Anthropic's dev container uses the same default-deny idea through an iptables script, and says the skip flag should be paired with egress restrictions[[2]](#cite-2). If you would rather not assemble and test this yourself, the [WOWHOW Agent Sandbox Kit](/product/agent-sandbox-kit) ($29) ships the hardened Docker config, a Squid default-deny allowlist and a smoke test that proves the egress rules hold. The catch: proxy variables only constrain tools that honor them. curl, npm and git over HTTPS do. Raw TCP clients do not, but on an internal: true network they have no route anyway, which is why the internal network does the real enforcement and the proxy only supplies the exception list. When gVisor (runsc) is worth it gVisor is an application kernel. Its Sentry implements the Linux interface in Go and, per the docs, does not pass system calls through to the host kernel. A Gofer process mediates file access[[8]](#cite-8). The host kernel sees a handful of calls from the Sentry instead of everything the agent's processes issue, so a kernel bug reachable from a syscall is harder to hit. It runs as an OCI runtime, so Docker treats it as a drop-in. Register it: sudo /usr/local/bin/runsc install sudo systemctl reload docker docker run --rm --runtime=runsc hello-world runsc install edits Docker's runtime configuration for you[[9]](#cite-9). Install the binary first using gVisor's tarball or apt package. After that, add --runtime=runsc to the hardened docker run above. For no network at all, runsc accepts --network=none, which leaves only a loopback[[11]](#cite-11). The price is compatibility and speed. gVisor's compatibility table for amd64 covers 352 syscalls: 290 implemented fully or partly, 62 not at all. Unimplemented examples include userfaultfd, perf_event_open (returns no such device), io_uring_register and vmsplice. io_uring and ptrace are only partly supported[[10]](#cite-10). For an agent that runs npm, pytest and git, this rarely bites. It bites profilers, debuggers using perf, and anything built on io_uring. On performance, gVisor's own page says CPU-bound work runs natively while syscall-heavy and small-file, VFS-heavy workloads pay the most, and it recommends the Systrap platform for best performance[[12]](#cite-12). A big node_modules install is exactly the file-heavy case, so time it before you commit. When a microVM is justified A microVM gives the workload its own kernel. A guest kernel exploit lands inside the VM, and the attacker still needs a hypervisor escape. Anthropic's sandbox page makes the same call: a dedicated VM is the strongest separation and fits untrusted code or policy that demands kernel-level separation[[4]](#cite-4). Justify it when: - Several customers or teams share one host (multi-tenant agents). - You run CI runners that execute pull-request code from strangers. - You build a Codex-cloud-style service where each task gets a fresh machine. Firecracker needs read/write access to /dev/kvm on x86_64 or aarch64 Linux and advertises boot under 125 ms and under 5 MiB overhead per VM[[13]](#cite-13). The one-liner, from its getting-started guide, boots from a JSON config holding the kernel and rootfs: sudo ./firecracker --api-sock /tmp/firecracker.socket --config-file vm-config.json Building the kernel image, rootfs and tap networking is a project of its own[[14]](#cite-14). Kata Containers wraps a lightweight VM behind a containerd shimv2 runtime so Kubernetes can schedule it like a pod, and kata-runtime check tests whether a host can run it[[15]](#cite-15). Follow the Kata install guide for the runtime-class registration rather than copying a snippet from memory. For a single developer who wants VM isolation without the assembly, Docker Sandboxes (a microVM with its own Docker daemon) is the lower-effort route Anthropic points to[[4]](#cite-4). Apple container on macOS 26 Apple's open-source container tool runs Linux containers as lightweight virtual machines on a Mac. It needs Apple silicon, supports macOS 26 only, is Apache-2.0, and builds on the Containerization Swift package. Install the signed package from the GitHub releases page, then: container system start container run --rm alpine echo hello The README says the project is under active development, release versions are product versions rather than semantic versions, and experimental features may change[[16]](#cite-16). Which one to pick Solo developer, trusted repo, Linux or Mac: hardened Docker plus the egress proxy, then the vendor's built-in sandbox inside it. Running agents you cannot supervise on code you did not write: add --runtime=runsc if your toolchain passes a smoke run, or move to a microVM. Selling agent runs to other people: microVM, no debate. Whichever you choose, cap the money side too, since a contained agent can still burn tokens. See [Claude Code spend limits and Codex runaway bills](/blogs/claude-code-spend-limit-hard-caps-codex-runaway-bill-2026), price a run with the [agent run cost simulator](/tools/agent-run-cost-simulator), and check that the Codex daemon is not leaving state behind in [this disk usage guide](/blogs/codex-cli-daemon-background-process-disk-usage-how-to-turn-off-2026). Quick answers Is --dangerously-skip-permissions safe inside Docker? Safer, not safe. The container limits file and process damage, but Anthropic warns a malicious project can still exfiltrate anything reachable inside it, including Claude credentials. Add egress restrictions, avoid mounting host secrets, and use a non-root user, which the flag requires. Does Docker isolate the kernel? No. Containers share the host kernel and rely on namespaces, cgroups, capabilities and seccomp. That is enough against a misbehaving agent and not enough against a determined attacker with a kernel exploit, which is the gap gVisor and microVMs close. Is gVisor or a microVM stronger? A microVM, in general, because the boundary is a hypervisor and a separate guest kernel. gVisor shrinks the host kernel surface but still runs on the host kernel. gVisor is easier to adopt because it plugs into Docker as --runtime=runsc. What does Codex do by default for network access? It is off. The default preset runs workspace-write with network disabled, and you enable it with network_access = true under [sandbox_workspace_write]. Using --yolo removes the sandbox entirely, so put it inside a container. Can I use Apple container to sandbox agents on a Mac? Yes, on Apple silicon with macOS 26. It runs each Linux container as a lightweight VM. It is under active development, so pin the version and test before relying on it for anything unattended. Sources 1. Claude Code: configure the sandboxed Bash tool (accessed 16 October 2026) 2. Claude Code: development containers (accessed 16 October 2026) 3. OpenAI Codex: agent approvals and security (formerly developers.openai.com/codex, accessed 16 October 2026) 4. Claude Code: choose a sandbox environment (accessed 16 October 2026) 5. Docker Engine security (accessed 16 October 2026) 6. docker container run reference (accessed 16 October 2026) 7. Docker seccomp security profiles (accessed 16 October 2026) 8. gVisor documentation (accessed 16 October 2026) 9. gVisor installation (accessed 16 October 2026) 10. gVisor Linux amd64 syscall compatibility (accessed 16 October 2026) 11. gVisor networking (accessed 16 October 2026) 12. gVisor performance guide (accessed 16 October 2026) 13. Firecracker project site (accessed 16 October 2026) 14. Firecracker getting started (accessed 16 October 2026) 15. Kata Containers repository (accessed 16 October 2026) 16. Apple container repository (accessed 16 October 2026) Every product mentioned is available at wowhow.cloud — pay once, ship forever. --- Originally published at wowhow.cloud

@S1r1u5_ oh nvrm I might be stupid: github.com/firecracker-microvm/firecracker/securi… I was looking at this a few weeks ago and got it mixed up

Beyond Isolates: How MicroVMs are Redefining Edge Function Performance Moving Beyond the Isolate Paradigm The serverless and edge computing landscape is currently undergoing a significant shift. For years, the industry standard for fast, ephemeral execution has been the V8 isolate. However, as infrastructure demands grow and security requirements tighten, developers are rethinking the balance between speed and isolation. Netlify recently made headlines by migrating their Edge Functions away from V8 isolates and onto Firecracker microVMs. This transition led to a dramatic reduction in median warm latency, dropping from the 25-40 ms range down to a blistering 5-6 ms. For those familiar with traditional virtualization, this sounds counterintuitive. We usually categorize isolates as the lightweight, high-performance option and virtual machines as heavy, slow, and resource-intensive. To understand why this change makes sense, we need to peel back the layers of the architecture and look at what happens under the hood when a request hits the edge. The performance gains reported are not just about the runtime itself but about the elimination of unnecessary network hops and the clever orchestration of microVM lifecycles. !Blog Image The Anatomy of an Isolate A V8 isolate functions as a discrete heap and execution context contained within a single process. By utilizing a single runtime instance to manage thousands of these isolated contexts, platforms achieve remarkably fast startup times. Because there is no need to boot a kernel or manage a separate process for every tenant, isolates are effectively the speed-kings of serverless functions. However, this speed comes at a cost regarding the isolation boundary. In a shared-process model, the security wall between your code and another tenant's code is maintained by the memory safety mechanisms of the engine itself. If that engine has a vulnerability, or if the runtime environment shares too many system-level resources, the isolation is significantly weaker than what hardware virtualization provides. Netlify’s move underscores a vital engineering principle: as the scale of deployments increases, the risk surface area grows, and hardware-backed isolation becomes a necessary trade-off. !Blog Image Rethinking Latency at the Edge Previously, Netlify handled high-volume traffic by routing requests out of their primary network to a separate execution service and back. This round-trip, combined with the overhead of the existing architecture, created the 25-40 ms latency floor. By redesigning the compute layer to reside directly inside the edge network, the system now functions in a more unified pipeline: 1. Edge nodes handle TLS termination and request routing. 2. Compute nodes manage the microVM lifecycle and cache function images locally. 3. The control plane coordinates the entire orchestration layer. By keeping the execution path contained within a single network environment, the system drastically reduces the latency previously lost to the network backhaul. The MicroVM Performance Secret: Snapshots and Memory Mapping If we assume a traditional VM boot process, we are talking about hundreds of milliseconds or even seconds. To achieve a single-digit millisecond response time, the system cannot perform a standard cold boot. Netlify achieves this by treating the microVM as an ephemeral entity that uses snapshots for instantaneous restoration. Memory-Mapped Images The function code is bundled as an uncompressed EROFS (Enhanced Read-Only File System) image. By memory-mapping this image, the guest VM does not need to load the entire bundle into memory. Instead, the guest kernel reads only the specific pages of code required to execute the function. Because this is done via memory mapping rather than standard file I/O, the performance hit is negligible, allowing the function to begin execution immediately. The Lifecycle of a Snapshotted VM When a microVM goes idle, the platform does not simply terminate it without a plan. It captures the state of the VM, including memory contents and emulated device states, into a snapshot. Subsequent requests can be served by restoring from these snapshots, effectively bypassing the entire OS boot sequence. This is a critical departure from traditional serverless cold starts. !Blog Image However, there are technical challenges with snapshotting, specifically regarding guest state persistence. If a guest VM resumes from the same snapshot multiple times, it must ensure that unique values like random tokens or identifiers are handled correctly. Systems typically address this using technologies like VMGenID to trigger re-seeding of random number generators upon restoration, ensuring that every "clone" is unique enough to maintain security invariants. Routing and Sticky Compute Nodes Restoring a snapshot is only efficient if the necessary data is already present on the compute node. To solve this, the infrastructure utilizes rendezvous hashing. By assigning specific functions to specific nodes, the system ensures that the most frequently used functions have their images and snapshots already primed in memory. This approach does come with a potential downside: hotspots. If a single function receives a massive influx of traffic, a single compute node could be overwhelmed. To mitigate this, the routing logic is designed to be elastic. If traffic patterns exceed predefined thresholds, the system relaxes the strict hash, spreading the load across a broader pool of nodes. While this might lead to a cold start for a small percentage of requests, it ensures the overall system remains resilient and available. Current benchmarks suggest that only about 1.2 percent of invocations face a cold start, which is a testament to the effectiveness of this routing strategy. Practical Benchmarking If you are skeptical about these latency numbers, the best way to verify them is to run your own experiments. You can measure the time-to-first-byte (TTFB) using a standard CLI command to see exactly how your functions are performing under load. for i in $(seq 1 50); do curl -s -o /dev/null -w '%{time_starttransfer}\n' https://your-site.netlify.app/your-edge-path done | sort -n | awk '{a[NR]=$1} END {print "p50:", a[int(NR*0.5)], "p99:", a[int(NR*0.99)]}' By comparing this result against a static asset on the same site, you can isolate the specific time added by the function execution itself. It is also worth noting that if you wish to experiment with Firecracker virtualization on your own hardware, you will need a machine capable of supporting KVM. The official Firecracker documentation provides an excellent roadmap for getting started with snapshotting and custom guest kernels. Architectural Considerations and Future Limits While the underlying infrastructure has changed, the developer experience remains unchanged. You continue to write, test, and deploy your code exactly as you did before. There is no manual migration or configuration update required to take advantage of this new compute model. As of now, the current constraints on compute duration, memory, and package size remain in place. These limits were originally established to accommodate the constraints of the old isolate-based runtime, but they are not inherent to microVM technology. As the ecosystem matures, we can likely expect these limits to be revisited, potentially allowing for more complex applications and larger runtime environments at the edge. Ultimately, the shift from isolates to microVMs demonstrates that performance at the edge is not solely determined by the "lightness" of the runtime. It is determined by the intersection of smart architectural design, efficient state management, and the ability to reduce overhead at every stage of the request path. By choosing hardware-level isolation, providers are opting for a more robust security model that doesn't have to sacrifice speed, provided they have the engineering rigor to implement snapshotting and intelligent routing effectively. Reference - Edge Functions on MicroVMs: Why Netlify Left V8 Isolates - Firecracker Documentation - Netlify Official Website - AWS Firecracker GitHub