Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-42275

CVE-2026-42275: Netfoundry Zrok Path Traversal Vulnerability

CVE-2026-42275 is a path traversal flaw in Netfoundry Zrok's WebDAV backend that allows symlink following to access files outside the shared root. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2026-42275 Overview

CVE-2026-42275 is a path traversal vulnerability [CWE-22] in zrok, an open-source platform from NetFoundry for sharing web services, files, and network resources. Versions prior to 2.0.2 contain a flaw in the WebDAV drive backend (davServer.Dir) that normalizes lexical path traversal but fails to block symbolic link following. Remote WebDAV consumers can exploit symlinks inside a shared DriveRoot to read files outside that root. On shares lacking operating system permission restrictions, attackers can also write or overwrite arbitrary files accessible to the zrok process. The maintainers patched the issue in version 2.0.2.

Critical Impact

Remote attackers connecting to an exposed zrok WebDAV share can read, write, or overwrite files anywhere on the host filesystem accessible to the zrok process, leading to data disclosure and potential host compromise.

Affected Products

  • NetFoundry zrok versions prior to 2.0.2
  • zrok WebDAV drive backend component (davServer.Dir)
  • Self-hosted and managed zrok deployments sharing local directories via WebDAV

Discovery Timeline

  • 2026-05-08 - CVE-2026-42275 published to the National Vulnerability Database
  • 2026-05-08 - Last updated in NVD database

Technical Details for CVE-2026-42275

Vulnerability Analysis

The vulnerability resides in zrok's WebDAV backend implementation, specifically the davServer.Dir handler. The handler enforces a DriveRoot boundary by lexically normalizing requested paths, stripping .. sequences and resolving relative components before serving content. This normalization protects against classic dot-dot-slash traversal but does not resolve symbolic links present inside the shared directory tree.

When the zrok process encounters a symlink that points outside DriveRoot, it follows the link and operates on the target. A remote WebDAV consumer can therefore read sensitive files such as configuration files, private keys, or credentials located anywhere the zrok process can access. If the share does not rely on operating system file permissions to constrain writes, the same primitive enables file overwrite, which can be used to tamper with binaries, scripts, or configuration to achieve persistence or code execution.

Root Cause

The root cause is incomplete path containment in davServer.Dir. Lexical normalization operates on the requested URL path, but the filesystem layer dereferences symbolic links transparently. Without an explicit check that the resolved target remains within DriveRoot, the boundary intended by the operator is bypassed. This is a classic symlink-following weakness layered on top of a WebDAV file service.

Attack Vector

The attack requires network access to a zrok WebDAV share. An attacker who can place a symlink inside the shared DriveRoot, either through legitimate write access or by socially engineering an operator, can then request the symlink path over WebDAV. The zrok server follows the link and returns or modifies the target file. No authentication is required when the share is configured without OS-level permission restrictions.

text
// Patch reference from openziti/zrok commit 459bcfc1e121decae1b1d11c37ad94e4ed5bbf2e
 .vscode
 .contexts
 CLAUDE.md
-/.claude/
+.claude
+.codex
 AGENTS.md
 *.db
 /automated-release-build/

Source: openziti/zrok commit 459bcfc. The release branch v2.0.2_drive_symlinks introduces symlink containment in the WebDAV backend. See the GitHub Security Advisory GHSA-74m3-9qvm-rp9h for full technical details.

Detection Methods for CVE-2026-42275

Indicators of Compromise

  • WebDAV requests (PROPFIND, GET, PUT, MOVE) targeting paths inside a zrok share that resolve through symbolic links
  • Unexpected symbolic links present under a configured DriveRoot pointing to locations such as /etc, /root, /home, or zrok configuration directories
  • Access or modification timestamps on sensitive host files that correlate with zrok process activity
  • zrok process logs showing successful file operations on paths outside the intended DriveRoot

Detection Strategies

  • Audit each DriveRoot filesystem tree with find <DriveRoot> -type l -exec ls -l {} \; to enumerate every symlink and verify each target stays inside the root
  • Enable verbose access logging on the zrok WebDAV backend and review requests for paths that reference directories not created by authorized users
  • Compare process-level file access (via auditd or eBPF tooling) against the declared DriveRoot to identify out-of-bounds reads and writes

Monitoring Recommendations

  • Forward zrok access logs and host file integrity events to a central analytics platform and alert on writes to system directories by the zrok process user
  • Monitor for creation of new symbolic links inside any DriveRoot and require operator review before exposure
  • Track installed zrok versions across the environment and flag any host running a release earlier than 2.0.2

How to Mitigate CVE-2026-42275

Immediate Actions Required

  • Upgrade all zrok deployments to version 2.0.2 or later, which adds symlink containment in davServer.Dir
  • Inventory every DriveRoot used by zrok WebDAV shares and remove symbolic links that point outside the root
  • Run the zrok process under a dedicated, least-privileged operating system account so that filesystem permissions limit reachable files
  • Temporarily disable WebDAV shares that cannot be patched immediately, especially those exposed over untrusted networks

Patch Information

The fix is included in zrok 2.0.2. Reference the GitHub Release v2.0.2, the upstream commit on the v2.0.2_drive_symlinks branch in openziti/zrok commit 459bcfc, and the coordinating GitHub Security Advisory GHSA-74m3-9qvm-rp9h.

Workarounds

  • Place each DriveRoot on a dedicated filesystem or mount that does not provide a path to sensitive host data
  • Enforce strict OS-level permissions on the zrok process user so that reads and writes outside DriveRoot are denied by the kernel
  • Reject or remove symbolic links during ingestion of files into shared directories until the upgrade to 2.0.2 is complete
bash
# Inventory symbolic links inside a zrok DriveRoot and flag targets outside the root
DRIVE_ROOT="/var/lib/zrok/share"
find "$DRIVE_ROOT" -type l -printf '%p -> %l\n' | \
  while IFS= read -r line; do
    target=$(readlink -f "${line%% -> *}")
    case "$target" in
      "$DRIVE_ROOT"/*) ;;
      *) echo "OUT-OF-ROOT: $line (resolves to $target)" ;;
    esac
  done

# Upgrade zrok to the patched release
zrok version
# Replace the binary with the v2.0.2 release artifact, then restart the service
systemctl restart zrok

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.