gVisor does not protect against attacks on components that start the sandbox, CPU side channels such as Spectre style attacks, or an exploit inside the sandboxed workload that reaches whatever the sandbox is allowed to touch. It targets one thing: stopping untrusted code from exploiting the host's Linux kernel.
What gVisor is for
gVisor describes itself as an open source workload isolation solution for running untrusted code, containers and applications. It is an application kernel that runs in user space. It intercepts the workload's system calls and page faults and handles them with its own Go implementation, called the Sentry, which makes only limited calls to the host kernel.
Because the workload never talks to the host kernel directly, a whole class of kernel exploits has no path in. That is the protection. The rest of this post covers what falls outside it.
The gaps, from the project's own documentation
| Gap | What it means |
|---|---|
| Higher level components | An exploit in the container runtime that starts the container without gVisor bypasses the sandbox. The docs give containerd as an example |
| CPU side channels | gVisor intercepts system calls and page faults only, so the workload can use the CPU freely within cgroup limits. Mitigation sits at the host kernel or hardware level |
| Exploits inside the workload | If a web app inside the sandbox is exploited, the attacker still has what the sandbox grants |
| Insecure architecture | The security model says a sandbox is not a substitute for a secure architecture |
| Host services | An exploitable network service on the host stays exploitable |
The same documentation adds that different customer workloads should run in different sandboxes, so a malicious customer cannot leak data from, or exploit, another customer's workload. It also mentions a runtime monitoring feature that can act as an intrusion detection mechanism for the sandboxed workload.
How to plan around the gaps
Keep the launcher honest. If the thing that decides whether to use the sandbox can be tricked into skipping it, the sandbox is optional. Restrict who can create workloads, and verify the runtime in use.
Treat the inside as compromised. Give the sandbox only the data and credentials the job needs. Mount inputs read only. Do not place long lived secrets inside.
Separate tenants. One sandbox per customer or per job, not one shared sandbox.
Control the network. A sandboxed workload with open network access can still send out what it can read.
Patch the host. gVisor reduces exposure to the host kernel but does not remove the need to keep the host and its services current. For a related question, see whether containers need the host kernel patched.
A short checklist
- Confirm the runtime is actually gVisor for the workloads you intend, not just configured somewhere.
- Give each tenant or job its own sandbox.
- Minimize mounts and secrets.
- Restrict outbound network access.
- Keep the host patched and watch for runtime alerts.
For a wider comparison, read which sandbox fits which code and the gVisor runtime deep dive.
Safeguard's dependency and image scanning looks at what goes into the workload, not at the sandbox. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does gVisor replace a virtual machine?
Not by definition. gVisor's documentation describes it as different from both a hypervisor and a system call filter, and lists the cases it does not cover.
If the workload is exploited inside gVisor, what can the attacker reach?
Whatever the sandbox was configured to allow, such as mounted data and network access. gVisor limits escape to the host, not access within the sandbox.
Sources
Last reviewed: 19 October 2026.
