Isolating untrusted browsers in homelabs: why air-gapped browsing matters for homelab admins

Chrome shipped patches for CVE-2026-3909 and CVE-2026-3910 as an out-of-band emergency update, but the prior scheduled release had already gone out 48 hours earlier without them. That 48-hour window, during which both vulnerabilities were confirmed as actively exploited in the wild, is not an edge case. It is the normal condition. Google’s own Threat Intelligence Group tracked 90 zero-days exploited in the wild across 2025, up from 78 in 2024. The gap between discovery and patch reaching your machine is real, measurable, and recurring.

The homelab is not a hardened enterprise perimeter. Auto-update may be on, but Chrome’s update rollout is gradual; a particular machine can sit on an unpatched version for days or longer without any visible indication. Patching faster than the rollout window closes is not a reliable strategy on its own.

The exploit path that patching alone cannot close

CVE-2026-3909 targeted Skia, Chrome’s 2D graphics rendering library. A crafted webpage triggers an out-of-bounds write during compositing, corrupting memory in the renderer process. CVE-2026-3910 is a type confusion bug in V8: JavaScript from a malicious page causes the engine to misinterpret an object’s type, writing attacker-controlled data into memory at an arbitrary address within the renderer.

Neither of these exploits stops at the renderer. Chrome’s renderer sandbox uses a combination of seccomp-bpf and a broker process to limit what the renderer can do directly, but a sandbox escape is a separate step and both CVEs were chained with exactly that in mind. Once the renderer process is compromised, the attacker targets the browser service process or the kernel directly, reaching the host. The renderer sandbox is a speed bump, not the final boundary. When the exploit is good enough to clear it, the browser process runs as your user on your host. Everything that user can reach is now reachable by the attacker.

On a homelab host running Proxmox, a NAS, internal DNS, or any service bound to the local network, that is a meaningful blast radius.

What browser isolation homelab actually means without a second physical network

Air-gapped browsing in a homelab does not require a second physical machine or a separate VLAN dedicated exclusively to internet traffic, though both help. The practical goal is to put the browser process in a container of some kind, so that a full compromise of that process does not translate directly into access to the host filesystem, the host network stack, or any homelab service.

There are two credible approaches on a Linux host: Firejail browser sandboxing with a network namespace, and a disposable VM running nothing but the browser.

Firejail: what it actually isolates

Firejail is a SUID sandbox that wraps an application in a set of Linux namespaces before it starts. For a browser, the relevant namespaces are the mount namespace (which gives the browser a private, restricted view of the filesystem), the network namespace (which can limit or completely cut off direct access to the host network stack), and the PID namespace (which hides the rest of the host’s process table from the sandboxed process).

Run Chrome under Firejail with the existing Chrome profile:

bash
firejail –profile=/etc/firejail/chromium.profile chromium

The shipped Chromium profile in /etc/firejail/chromium.profile blacklists large portions of the filesystem, including /etc, /var, and home directory subdirectories that have no business being readable by a browser. It mounts /tmp as a private tmpfs. The browser process and all its children inherit these restrictions.

The seccomp-bpf filter is where the kernel boundary gets drawn. Firejail installs a BPF programme that intercepts every syscall the browser process makes and either allows or kills it. Calls like ptrace, mount, and unshare are blocked by default. A compromised renderer that attempts to call ptrace on the Firejail parent or mount a FUSE filesystem to reach /proc/sysrq-trigger hits this filter and gets SIGKILL. The browser dies; the host does not.

To add AppArmor confinement on top, enable it in the profile:

bash
firejail –apparmor –profile=/etc/firejail/chromium.profile chromium

This requires the firejail AppArmor profile to be loaded. Load it with:

bash
sudo apparmor_parser -r /etc/apparmor.d/firejail-default

The AppArmor profile adds mandatory access control at the kernel level, independent of the seccomp filter. Where seccomp blocks by syscall number, AppArmor blocks by object: specific files, sockets, and capabilities. A compromised browser that somehow passes the seccomp filter still cannot write to /home/user/.ssh or connect to 192.168.1.0/24 if the AppArmor profile says no.

For network namespace isolation, the key flag is --net=none for a fully isolated namespace, or --net=<interface> to give the sandboxed browser its own virtual interface routed only to the internet, with no route to your homelab subnets:

bash
firejail –net=none –profile=/etc/firejail/chromium.profile chromium

With --net=none, the sandboxed browser has a loopback interface only. Lateral movement from a compromised browser process to any homelab service becomes a network-level impossibility rather than a policy preference.

The disposable VM: higher overhead, higher assurance

Firejail narrows the attack surface significantly, but it is still a process-level boundary running on the same kernel. A kernel vulnerability in the wrong syscall path could, in principle, escape it. The Arch Wiki notes this plainly: running untrusted code is never safe; sandboxing changes the odds, not the absolute outcome.

The disposable VM approach accepts that trade-off by moving the browser onto a separate kernel entirely. Spin up a lightweight VM in Proxmox or KVM, install only a browser and a minimal desktop, take a snapshot, and revert to that snapshot after every session. A full sandbox escape from the browser reaches the VM’s kernel, not the host’s. The VM’s network interface connects to a restricted VLAN or a dedicated firewall rule set that permits outbound internet access and nothing else. No route to 10.0.0.0/8 or 192.168.0.0/16, no DNS resolution of internal hostnames.

The overhead is real: a minimal Debian VM with a browser uses roughly 512 MB RAM and takes 20–30 seconds to revert a snapshot. That is the cost. The assurance level is higher than any process sandbox can offer, because the blast radius is bounded by the VM boundary, and the snapshot revert wipes any persistence the attacker established in the guest.

Choosing the right layer for your threat model

Firejail with a network namespace and AppArmor is appropriate when the risk is an opportunistic drive-by exploit from an untrusted webpage, and you are browsing from a Linux desktop that already runs homelab services. The configuration takes under an hour to get right, and the syscall filter alone is enough to stop most post-exploitation tooling from running at all.

The disposable VM is the right choice when the untrusted content is specifically targeted: testing a link from an unknown source, visiting a site flagged as potentially malicious, or browsing anything you would not open on your main machine without a second thought. The VM boundary survives a renderer exploit, a sandbox escape, and even a kernel exploit in the guest kernel without touching the Proxmox host or anything on the homelab network.