gVisor's VFS use-after-free: the fix shipped five weeks before the CVE

The fix shipped before the CVE

On September 4, 2026, Google published gVisor release 20260831.0. Five weeks later, on October 9, the NVD registered CVE-2026-95702 against the same software.

For anyone running gVisor to sandbox untrusted containers, the fix was available and the CVE was not. That ordering is the point of this piece.

What the vulnerability is

gVisor runs containers inside a user-space kernel it calls the sentry. The sentry intercepts syscalls from the container and emulates the kernel interface, so the container never talks to the real host kernel directly. The container is isolated by a software layer, not just by the host kernel, and that boundary is what gVisor is for.

The bug sits in the sentry's VFS layer. A local attacker holding standard in-sandbox container privileges could double-free the backing MemoryFile from an in-sandbox overlay filesystem. A double-free of a memory object is a use-after-free: the object is freed, then freed again, and the second free corrupts the allocator's internal state. The NVD scores it CVSS 4.0 8.5 HIGH, local, low complexity, low privileges, high container impact.

The result is code execution in the host sentry process. The attacker does not escape to the host. The sentry remains confined by host-level Linux seccomp and namespace boundaries, so the blast radius is the sentry process itself, not the machine running it.

Why the blast radius still matters

A container-privileged attacker reaching code execution inside the sentry is a boundary break, even if the host stays out of reach. The sentry is the component doing the sandboxing. If it runs untrusted code, the isolation it provides to the containers it supervises is compromised. In a multi-tenant deployment where one sentry supervises several untrusted containers, a compromise of the sentry is a compromise of the supervisor, not just of one container.

That is what makes this a high-priority patch for anyone running gVisor. The tool's value is the boundary, and this bug crosses it.

The release notes are the advisory

There is no GHSA for this CVE, and no dedicated security bulletin. The fix is a set of VFS refcounting and umount-check commits that shipped inside a routine release, not a security patch with its own advisory. The release notes name the VFS refcounting fix (e4efb89c7) and the umount-check change for bind mounting (90bc4fc36); the NVD lists three fix commits, and the vendor does not isolate which single commit closes the double-free.

That changes the defensive posture. You cannot wait for a CVE or a security bulletin to tell you when to patch gVisor. The only public signal that a security-relevant fix shipped is a set of VFS memory-management commits in an ordinary release, and the CVE arrives weeks later. For gVisor, and for similar projects that publish fixes without a dedicated security channel, the release notes are the de facto security advisory. Tracking releases, not CVE feeds, is the reliable way to catch these.

The dates line up with that pattern: fix released 2026-09-04, CVE published 2026-10-09, this scan ran 2026-10-11.

What to do

If you run gVisor below 20260831.0, upgrade to 20260831.0 or later. No workaround is documented in the public record. If you run a multi-tenant deployment, confirm every sentry is on the fixed release, and treat the VFS refcounting commits in future routine releases as security-relevant until the project adds a dedicated advisory channel.

As of 2026-10-11 there is no KEV listing and no in-the-wild exploitation evidence. This is a patch-priority item, not an active-exploitation alert.

Sources

• NVD record CVE-2026-95702 (published 2026-10-09)
• gVisor release 20260831.0 (published 2026-09-04)
• gVisor fix commit 25c7514 (overlayfs refcount)
• Debian Security Tracker, CVE-2026-95702 (independent Tier-1 corroboration)

Feature image: feature_gvisor_uaf.png (rendered with AI; provenance in the issue comment)

Feature image caption: A translucent glass container box on a dark technical background with a red crack propagating through one wall and a small glowing memory-pointer fragment escaping through the crack, representing a use-after-free escape from a container into the sandbox supervisor. Rendered with AI.

This article was drafted with AI/LLM assistance and reviewed by a human before publication. All factual claims were checked against the public sources cited above. The feature image was generated with AI. See How we use AI for the full workflow.