CVE-2026-107935: 
Podman vulnerability analysis and mitigation

CVE-2026-107935 is a path traversal vulnerability (CWE-22) in gvproxy, the network forwarder component of the gvisor-tap-vsock package. The unauthenticated /services/forwarder/expose REST endpoint fails to validate caller-supplied socket paths, enabling an attacker to delete arbitrary files on the host system. Affected versions span gvisor-tap-vsock 0.4.0 through 0.8.x (fixed in 0.9.0); Red Hat products including Podman Desktop, container-tools, and various RHEL 10 container images are also affected. The vulnerability was discovered by Lucas Celant of Red Hat, disclosed on October 9, 2026, and carries a CVSS v3.1 base score of 9.3 (Critical) (Red Hat Advisory, Github Advisory).

The root cause is improper path validation (CWE-22) in the port-forwarder's /services/forwarder/expose REST endpoint within gvproxy. When the endpoint is invoked with protocol=unix, the caller-supplied local field is passed without sanitization directly to os.Remove() followed by net.Listen("unix", ...) on the host filesystem. Because the endpoint is exposed unauthenticated on the VM gateway address (192.168.127.1:80), any process inside the guest VM — including an unprivileged container — can send a crafted HTTP POST to delete an arbitrary file owned by the gvproxy user on the host and replace it with a Unix socket inode. The fix, implemented in PR #718, removes the os.Remove() call entirely and instead closes listeners on gvproxy exit, so pre-existing host files can no longer be deleted or overwritten (Red Hat Bugzilla, GitHub PR #718).

Successful exploitation allows an unauthenticated attacker with access to the guest VM's internal network to delete or replace arbitrary files owned by the gvproxy user on the host, crossing the container/VM-to-host isolation boundary. Sensitive files such as SSH keys, kubeconfig files, and shell or registry configuration can be destroyed, leading to denial of service or enabling further attacks (e.g., socket-squatting to intercept communications). While the flaw does not directly provide arbitrary code execution or privilege escalation on the host, destruction of critical files can facilitate both. Confidentiality impact is rated None, but integrity and availability impacts are both rated High (Red Hat Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at the time of disclosure (Github Advisory). The EPSS score is approximately 0.298% (21st percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to already have code execution inside the guest VM or a container running within it, which limits the attack surface; however, no authentication is required to reach the vulnerable endpoint once inside the guest network (Red Hat Advisory).

1. Gain guest VM or container access: Obtain code execution inside a guest virtual machine or container managed by a vulnerable gvproxy instance (e.g., by running a malicious or compromised container image under Podman).
2. Identify the gvproxy gateway: Confirm the VM gateway address is reachable at 192.168.127.1:80 (the default internal network gateway where gvproxy's REST API listens unauthenticated).
3. Craft the malicious HTTP POST: Construct an HTTP POST request to http://192.168.127.1:80/services/forwarder/expose with a JSON body specifying protocol=unix and a local field set to the path of the target host file to delete (e.g., {"local": "/home/user/.ssh/authorized_keys", "remote": "...", "protocol": "unix"}).
4. Trigger arbitrary file deletion: Send the crafted request. The unvalidated local path is passed to os.Remove() on the host, deleting the specified file. The endpoint then calls net.Listen("unix", ...) on that path, replacing the deleted file with a Unix socket inode.
5. Achieve objective: Repeat for additional sensitive files (kubeconfig, shell configs, etc.) to cause denial of service, disrupt authentication, or position for further attacks via socket-squatting (Red Hat Bugzilla, GitHub PR #718).

• Network: Unexpected HTTP POST requests to http://192.168.127.1:80/services/forwarder/expose originating from inside a guest VM or container, particularly with protocol=unix and unusual local path values pointing outside expected socket directories.
• File System: Disappearance of files owned by the gvproxy user (e.g., SSH keys, kubeconfig, shell configs) replaced by Unix socket inodes (srwxrwxrwx permissions in ls -la output); unexpected .sock files appearing in sensitive directories such as ~/.ssh/, ~/.kube/, or /etc/.
• Logs: gvproxy logs showing net.Listen("unix", ...) calls to unusual or sensitive paths; HTTP access logs on the VM gateway recording POST requests to /services/forwarder/expose with anomalous local field values.
• Process: gvproxy process creating Unix socket files in directories unrelated to normal port-forwarding operations (Red Hat Bugzilla).

Upgrade gvisor-tap-vsock to version 0.9.0 or later, which removes the unsafe os.Remove() call from the forwarder's Unix socket code path (GitHub PR #718). Red Hat Podman Desktop and affected RHEL container images should be updated as patches become available via Red Hat advisories. As a network-level workaround until patching is complete, restrict access to the gvproxy REST API endpoint (192.168.127.1:80/services/forwarder/expose) using host-based firewall rules or network policies to prevent untrusted guest processes from reaching it. Avoid running untrusted container images on systems with vulnerable gvproxy versions (Red Hat Advisory).

Red Hat rated this vulnerability as "Important" rather than "Critical" in their internal classification, noting that exploitation requires prior code execution inside the guest VM and that the impact is bounded by the privileges of the unprivileged gvproxy user account (Red Hat Advisory). The Podman project acknowledged the issue via a post on Fosstodon, and the fix was contributed by Red Hat's Christophe Fergeau and merged into the upstream gvisor-tap-vsock repository on September 29, 2026 (GitHub PR #718). No significant broader media coverage or notable external researcher commentary has been observed beyond standard vulnerability database aggregation.