CVE-2026-107935: Gvisor-tap-vsock: gvisor-tap-vsock: unathenticated arbitrary file deletion on the host via /expose
A path traversal vulnerability was found in gvproxy, the network forwarder provided by the gvisor-tap-vsock package. The unauthenticated /services/forwarder/expose endpoint does not validate the caller-supplied socket path, allowing an attacker to delete arbitrary files on the host system.
Other sources
A path-traversal flaw was found in gvproxy (gvisor-tap-vsock) in the port-forwarder's /services/forwarder/expose REST endpoint. When invoked with protocol=unix, the caller-supplied local field was passed without any validation to os.Remove() followed by net.Listen("unix", ...) on the host filesystem. Because this endpoint is exposed unauthenticated on the VM gateway (192.168.127.1:80), a process inside the guest VM — including an unprivileged container — could send a single HTTP POST to delete an arbitrary file owned by the gvproxy user on the host and replace it with a unix-socket inode. This crosses the container/VM-to-host isolation boundary, allowing destruction of sensitive host files (SSH keys, kubeconfig, shell/registry configuration) and denial of service. The issue was fixed by removing the os.Remove() call so pre-existing files can no longer be deleted or overwritten.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who can reach the vulnerable endpoint?
The endpoint is exposed without authentication on the VM gateway at 192.168.127.1:80. A process running inside the guest VM, including an unprivileged container, can send the request.
What does an attacker need to do to trigger the issue?
The attacker needs to send a single HTTP POST to /services/forwarder/expose using protocol=unix and supply a socket path in the local field. No credentials or user interaction are required.
What host files are at risk?
An attacker can delete arbitrary files owned by the gvproxy user and replace them with a Unix-socket inode. The described impact includes destruction of host SSH keys, kubeconfig, and shell or registry configuration, as well as denial of service.
What is the available fix?
The issue was fixed by removing the os.Remove() call before creation of the Unix socket. Deploy a fixed version or build containing that change so existing files cannot be deleted or overwritten through this endpoint.