What is the CVSS score of CVE-2026-42275?

CVE-2026-42275 has a CVSS 3.1 base score of 8.7 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of zrok are affected by CVE-2026-42275?

CVE-2026-42275 affects zrok's WebDAV drive backend, enabling unauthenticated attackers to read arbitrary files and overwrite critical system files like SSH authorized_keys if a symlink precondition…. A patch is available.

How to fix or mitigate CVE-2026-42275?

Within 24 hours: inventory all zrok deployments and identify instances running WebDAV drive backend functionality. Within 7 days: upgrade zrok to version 2.0.2 or later (specifically incorporating commit 459bcfc1e121decae1b1d11c37ac94e4ed5bbf2e); audit shared directories for unexpected symlinks pointing outside DriveRoot. Within 30 days: review access logs for suspicious WebDAV path traversal attempts, validate symlink monitoring controls, and conduct post-upgrade validation testing.

zrok CVE-2026-42275

EUVD-2026-28511 HIGH

UNIX Symbolic Link (Symlink) Following (CWE-61)

2026-05-08 GitHub_M

GHSA-74m3-9qvm-rp9h

Path Traversal Zrok

8.7

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.7 HIGH

AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

May 08, 2026 - 05:01 EUVD

Source Code Evidence Fetched

May 08, 2026 - 04:34 vuln.today

Analysis Generated

May 08, 2026 - 04:34 vuln.today

CVE Published

May 08, 2026 - 03:45 nvd

HIGH 8.7

DescriptionGitHub Advisory

zrok is software for sharing web services, files, and network resources. Prior to version 2.0.2, the zrok WebDAV drive backend (davServer.Dir) restricts path traversal through lexical normalization but does not prevent symlink following. When a symbolic link inside the shared DriveRoot points to a location outside that root, remote WebDAV consumers can read files and-on shares without OS-level permission restrictions-write or overwrite files anywhere on the host filesystem accessible to the zrok process. This issue has been patched in version 2.0.2.

AnalysisAI

Remote path traversal via symlink following in zrok's WebDAV drive backend allows unauthenticated network attackers to read arbitrary files accessible to the zrok process and overwrite critical system files (such as SSH authorized_keys) outside the intended share boundary. Attack complexity is high because exploitation requires a pre-existing symlink inside the shared directory pointing outside DriveRoot-a precondition typically created through local access or misconfiguration, not by the attacker. EPSS data not provided; no CISA KEV listing indicates targeted rather than widespread exploitation. Vendor-released patch available in version 2.0.2 with commit 459bcfc1e121decae1b1d11c37ad94e4ed5bbf2e implementing symlink boundary validation.

Technical ContextAI

zrok is an open-source software from OpenZiti for sharing web services, files, and network resources. The vulnerability resides in the WebDAV drive backend implementation (davServer.Dir) in Go. WebDAV is an HTTP extension protocol enabling collaborative file editing. The affected code uses lexical path normalization (filepath.Clean) to prevent directory traversal attacks but does not evaluate symbolic links before filesystem operations. When a symlink within the shared DriveRoot resolves to a path outside that root, operations like OpenFile, Stat, Mkdir, and RemoveAll follow the symlink without boundary validation. The root cause is CWE-61 (UNIX Symbolic Link Following), where the application trusts the filesystem abstraction layer without verifying that dereferenced paths remain within the security boundary. The fix introduces resolveBoundedPath(), which iteratively resolves path components with symlink loop protection (255-hop limit) and validates each resolution against the canonical DriveRoot using filepath.EvalSymlinks and isWithinRoot checks.

RemediationAI

Upgrade to zrok version 2.0.2 or later, available at https://github.com/openziti/zrok/releases/tag/v2.0.2. The patch implements symlink boundary validation in resolveBoundedPath() preventing traversal outside DriveRoot while preserving internal symlink functionality. For environments unable to upgrade immediately, implement these compensating controls with noted trade-offs: (1) Audit shared directories for symlinks pointing outside the share root using 'find [share-path] -type l -exec readlink -f {} \;' and remove outbound links (trade-off: breaks legitimate internal symlinks if application depends on them). (2) Run zrok processes under restricted user accounts with minimal filesystem permissions using principle of least privilege-limit read access to only necessary paths and deny write access to sensitive files like /etc, /root, user .ssh directories (trade-off: may break legitimate share functionality if files outside minimal set are needed). (3) Deploy zrok in containerized environments with read-only root filesystems and explicit volume mounts only for intended share paths using Docker --read-only and --tmpfs flags (trade-off: requires container orchestration changes and may conflict with applications expecting writable filesystem). (4) If using zrok in public share mode, add authentication using zrok's access control features rather than --backend-mode drive with default unauthenticated access (trade-off: changes user access workflow and may not prevent exploitation if authenticated users are untrusted). These mitigations reduce but do not eliminate risk; upgrade remains the definitive solution.