zrok CVE-2026-42275

Exploitation requires that a symbolic link already exists inside the WebDAV-shared DriveRoot directory that points to a location outside that root. This symlink must be created through local filesystem access (shell, deployment scripts, application logic) prior to exploitation-attackers cannot create the symlink remotely via WebDAV itself. Additionally, the zrok share must be configured in public drive mode ('zrok share public --backend-mode drive [path]') which by default provides unauthenticated network access to the WebDAV endpoint. The zrok process must have filesystem permissions to read (for information disclosure) or write (for file overwrite attacks) the symlink target path. What LIMITS exploitation: Attack complexity is high (AC:H in CVSS) because the attacker cannot directly create the precondition symlink-it depends on local configuration or existing filesystem structure. Organizations sharing directories without pre-existing outbound symlinks and running zrok with restricted user permissions face significantly lower practical risk despite the high CVSS score. Environments using authenticated zrok share modes or containerized deployments with isolated filesystem namespaces add additional exploitation barriers.

Real-world risk is moderate despite the 8.7 CVSS score. The CVSS vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N accurately reflects network-based exploitation with high attack complexity due to the symlink precondition. The 'Changed' scope reflects boundary escape from WebDAV root to host filesystem. However, AC:H significantly constrains practical exploitation: attackers cannot directly create the required symlink via WebDAV-it must exist beforehand through local shell access, deployment automation, or application logic. This limits attack surface to environments where the shared directory already contains outbound symlinks (e.g., developers sharing entire home directories, containerized deployments mounting host paths with symlinks). No CISA KEV listing suggests exploitation is not widespread. EPSS score not provided but likely low given the niche product and high complexity. SSVC framework assessment: exploitation status is 'none' (no public evidence of active exploitation beyond disclosure), automatable is 'no' (requires precondition scanning), technical impact is 'total' (arbitrary file read/write). Priority should focus on zrok deployments exposing untrusted directories or running with elevated privileges. Organizations using default configurations with controlled share directories face lower immediate risk than CVSS suggests.

An attacker discovers a publicly accessible zrok WebDAV share at https://share.example.com/drive/. Through reconnaissance (e.g., error message analysis, public documentation), they determine the share was created with 'zrok share public --backend-mode drive ~/shared-docs'. The attacker knows or guesses that ~/shared-docs contains a symlink (perhaps a convenience link like 'logs -> /var/log/app' created by a developer for debugging). The attacker issues a WebDAV PROPFIND request to enumerate the share, identifies the 'logs' symlink, then sends HTTP GET requests through that symlink path to read arbitrary system files like /etc/passwd or application configuration files with database credentials. Using PUT requests, the attacker overwrites ~/.ssh/authorized_keys on the host (if the zrok process runs as a user account) to inject their SSH public key, gaining persistent shell access. Publicly available exploit code exists per GitHub advisory GHSA-74m3-9qvm-rp9h which includes proof-of-concept exploitation steps.