CVE-2026-107935: gvproxy Path Traversal Allows Unauthenticated Host File Deletion

Overview

A critical path traversal vulnerability, tracked as CVE-2026-107935, has been disclosed in gvproxy, the user-space network forwarder shipped as part of the gvisor-tap-vsock package. gvisor-tap-vsock provides the networking layer that lets a virtual machine or container talk to the host and the outside world in tools built around it — most notably Podman Desktop and several Red Hat Enterprise Linux-based products.

The flaw lives in gvproxy's unauthenticated /services/forwarder/expose endpoint, reachable from inside the guest VM or container over the gateway API. The endpoint accepts a caller-supplied socket path and passes it straight through to filesystem operations without validating it, letting an attacker inside the guest delete an arbitrary file owned by the host user and replace it with a Unix-socket inode. That is enough to cross the VM-to-host (or container-to-host) isolation boundary that gvisor-tap-vsock exists to enforce. NVD published the record on 2026-10-09 with a CVSS 3.1 score of 9.3 (Critical).

Technical Details

How It Works

gvisor-tap-vsock runs a small HTTP API on the host side of the VM/container gateway so that the guest can ask the host to expose ports and forward traffic. The /services/forwarder/expose endpoint is one of these calls, and in affected versions it is reachable without any authentication.

When a caller requests a Unix-socket forwarder (protocol: "unix"), gvproxy tries to clean up a possible stale socket at the target path before binding to it. The implementation did this by calling os.Remove() on the caller-supplied path with no validation that the path pointed at an actual leftover socket — or even that it stayed inside an expected directory. An attacker who can reach the gateway API from inside the guest could therefore:

1. Send a single HTTP POST to /services/forwarder/expose naming an arbitrary host file path and protocol: "unix".
2. gvproxy's cleanup logic deletes that file via os.Remove(), regardless of what it actually was.
3. gvproxy then calls net.Listen("unix", ...) on the same path, creating a new Unix-socket inode in place of the file that was just deleted.

Because the gateway API runs with the privileges of the host-side gvproxy process, this is enough to destroy security-sensitive files such as SSH authorized-keys files, kubeconfigs, and shell or container-registry configuration — or simply to cause a denial of service by deleting files the host process depends on.

Impact Assessment

Who Is At Risk

• Anyone running Podman Desktop, which bundles gvisor-tap-vsock to provide VM networking for its machine backend
• Red Hat Enterprise Linux 8, 9, and 10 systems with the gvisor-tap-vsock package installed, along with OpenShift Container Platform 4, OpenShift Dev Spaces, and OpenStack Platform 18.0, all of which bundle the component per Red Hat's own affected-products list
• Any workload running inside a VM or container whose networking is backed by gvisor-tap-vsock — a malicious or compromised guest process is the realistic attacker here, not a remote internet-based one
• Other desktop container tooling that vendors gvisor-tap-vsock/gvproxy for VM networking should be checked individually; we did not find an official advisory confirming or ruling out Rancher Desktop specifically, so treat that as unconfirmed rather than cleared

Attack Chain

1. Guest-side foothold — Attacker runs code inside a VM or container whose network stack is provided by gvisor-tap-vsock (e.g., a malicious container image, a compromised build job, or any code execution inside the guest).
2. Unauthenticated gateway request — Attacker sends one POST /services/forwarder/expose request to the host-side gateway API, specifying a unix protocol and a target path pointing at a sensitive host file.
3. Arbitrary deletion — gvproxy's unvalidated cleanup step deletes the targeted host file via os.Remove().
4. Socket inode replacement — gvproxy then creates a new Unix-socket listener at that same path, leaving the original file gone and a socket in its place.
5. Host compromise or DoS — Depending on which file was targeted, the result is loss of SSH access, broken kubeconfig/registry auth, or a crashed host-side service.

Mitigation

Immediate Actions

• Upgrade gvisor-tap-vsock (and any product bundling it, including Podman Desktop) to version 0.9.0 or later, which reworks Unix-socket cleanup to check that an existing path is actually a socket (fs.ModeSocket) before removing it, and rejects regular files and directories outright.
• Apply the corresponding Red Hat errata for your RHEL 8/9/10, OpenShift, or OpenStack Platform 18.0 deployment once available for your channel; track Red Hat Bugzilla 2548382 / Jira RHDESK-550 for product-specific fix timing.
• Where upgrading immediately isn't possible, the project's fix also added a --gateway-expose-all-protocols flag that is off by default in 0.9.0 — confirm you have not manually re-enabled unix/npipe protocol exposure on the gateway API unless you specifically need it.

Detection Opportunities

• Review host-side logs for gvproxy gateway requests to /services/forwarder/expose with protocol: "unix" targeting paths outside expected socket directories.
• Audit for unexpected disappearance of SSH authorized_keys, kubeconfig, or registry/shell configuration files on hosts running Podman Desktop or RHEL systems with gvisor-tap-vsock.
• Check for unexplained Unix-socket inodes appearing at paths that previously held regular files.

Defence-in-Depth

• Treat any VM or container backed by gvisor-tap-vsock as able to reach the host-side gateway API — don't rely on the gateway being "internal only" as a substitute for patching.
• Where supported, configure the new optional Bearer token authentication for the gateway API (--api-token-file or the GVISOR_API_TOKEN environment variable), added alongside this fix to prevent untrusted guest workloads from calling gateway endpoints at all.
• Limit what runs inside VMs/containers that rely on gvisor-tap-vsock for networking, especially build pipelines or environments that execute untrusted or third-party code.

Background

The fix shipped in gvisor-tap-vsock 0.9.0 and is tracked upstream across several pull requests in the containers/gvisor-tap-vsock GitHub repository: PR #681 ("prevent arbitrary file deletion via unix socket creation," tied to Red Hat Jira ticket RHDESK-550), PR #718 (reworking Unix-socket cleanup handling to stop removing pre-existing files before listening), and PR #724 (adding optional Bearer-token authentication to the gateway API endpoints). The same release also restricts the gateway's /expose endpoint to tcp and udp protocols by default, with a --gateway-expose-all-protocols flag needed to restore the old, riskier behavior.

Red Hat's own affected-products list for this CVE spans Red Hat Build of Podman Desktop (all versions) plus RHEL 8, 9, and 10 builds of the gvisor-tap-vsock package, OpenShift Container Platform 4, OpenShift Dev Spaces, OpenStack Platform 18.0, Edge Manager 1, and Red Hat's Hardened Images. We were able to independently corroborate the core technical details — the unvalidated path passed to os.Remove()/net.Listen(), the fix commits, and the Bugzilla/Jira tracking — through the upstream GitHub pull requests and Red Hat's bug tracker, beyond the base NVD record. We could not find an official advisory confirming whether other gvisor-tap-vsock consumers, such as Rancher Desktop, are affected; anyone running desktop container tooling built on this library should verify directly with that vendor rather than assume either way.

References

• NVD — CVE-2026-107935
• GitHub — containers/gvisor-tap-vsock PR #681: prevent arbitrary file deletion via unix socket creation
• GitHub — containers/gvisor-tap-vsock PR #718: Rework unix socket cleanup handling
• GitHub — containers/gvisor-tap-vsock PR #724: add Bearer token authentication to gateway API endpoints
• Red Hat Bugzilla — Bug 2548382