Summary
zrok versions 0.4.23 through 2.0.3 contain a path traversal flaw in the zrok2 copy sync pipeline that trusts attacker-controlled WebDAV or zrok drive paths.
By supplying crafted paths like /../outside.txt, an attacker can cause files to be written outside the intended local destination directory when synchronization occurs.
zrok versions 0.4.23 through 2.0.3 contain a path traversal flaw in the zrok2 copy sync pipeline that trusts attacker-controlled WebDAV or zrok drive paths.
By supplying crafted paths like /../outside.txt, an attacker can cause files to be written outside the intended local destination directory when synchronization occurs.
Affected context
The vulnerability appears in environments where zrok is used to synchronize files from WebDAV or zrok drive sources to a local filesystem using the zrok2 copy command.
It becomes relevant when remote endpoints can influence or control the paths that are stored in the source inventory and later passed into the sync pipeline.
In such setups, insufficient normalization and validation of incoming file paths allow traversal sequences to escape the intended destination root directory.
The vulnerability appears in environments where zrok is used to synchronize files from WebDAV or zrok drive sources to a local filesystem using the zrok2 copy command.
It becomes relevant when remote endpoints can influence or control the paths that are stored in the source inventory and later passed into the sync pipeline.
In such setups, insufficient normalization and validation of incoming file paths allow traversal sequences to escape the intended destination root directory.
Exploit preconditions
- Attack surface: The sync functionality of
zrok2 copyinteracting with WebDAV or zrok drive sources. - Required access: Ability to supply or control file paths on the remote WebDAV or zrok drive (e.g., by hosting or modifying content on the source).
- Trigger point: Execution of
zrok2 copywhere the source inventory records paths containing traversal segments like/../. - Why exploitation is possible: The sync pipeline passes unsanitized source paths directly to
FilesystemTarget.WriteStream, which does not enforce that writes stay within the selected local destination root.
- Attack surface: The sync functionality of
zrok2 copyinteracting with WebDAV or zrok drive sources. - Required access: Ability to supply or control file paths on the remote WebDAV or zrok drive (e.g., by hosting or modifying content on the source).
- Trigger point: Execution of
zrok2 copywhere the source inventory records paths containing traversal segments like/../. - Why exploitation is possible: The sync pipeline passes unsanitized source paths directly to
FilesystemTarget.WriteStream, which does not enforce that writes stay within the selected local destination root.
Why this happens
This issue stems from inadequate validation and canonicalization of file paths received from remote sources before using them in filesystem write operations.
The code path that builds the source inventory and later invokes FilesystemTarget.WriteStream relies on externally controlled paths without stripping traversal segments or re-checking that the resolved location remains under the chosen destination root.
Conceptually, this maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, where a component fails to constrain file system operations to an intended directory, enabling attackers to escape that boundary.
This issue stems from inadequate validation and canonicalization of file paths received from remote sources before using them in filesystem write operations.
The code path that builds the source inventory and later invokes FilesystemTarget.WriteStream relies on externally controlled paths without stripping traversal segments or re-checking that the resolved location remains under the chosen destination root.
Conceptually, this maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, where a component fails to constrain file system operations to an intended directory, enabling attackers to escape that boundary.
Potential impact
- Files may be written to arbitrary locations outside the designated sync destination directory.
- Attackers could create or overwrite configuration files on the local system.
- Sensitive local files or application data could be corrupted or replaced.
- Local privilege escalation may be possible if critical system or application files are overwritten in permissive environments.
- Files may be written to arbitrary locations outside the designated sync destination directory.
- Attackers could create or overwrite configuration files on the local system.
- Sensitive local files or application data could be corrupted or replaced.
- Local privilege escalation may be possible if critical system or application files are overwritten in permissive environments.
General mitigation guidance
Effective mitigation focuses on ensuring that all file paths derived from external sources are constrained to an expected directory and validated before use.
Common patterns include:
- Normalizing and canonicalizing paths, then verifying that the final resolved path remains under the intended destination root.
- Rejecting or sanitizing any path that contains traversal tokens (
.., absolute path prefixes, or mixed separators) before use in file operations. - Encapsulating filesystem writes behind APIs that enforce directory boundaries rather than exposing raw path handling throughout the codebase.
- Applying least-privilege principles to the processes performing synchronization so that even misdirected writes have limited impact on the system.
Effective mitigation focuses on ensuring that all file paths derived from external sources are constrained to an expected directory and validated before use.
Common patterns include:
- Normalizing and canonicalizing paths, then verifying that the final resolved path remains under the intended destination root.
- Rejecting or sanitizing any path that contains traversal tokens (
.., absolute path prefixes, or mixed separators) before use in file operations. - Encapsulating filesystem writes behind APIs that enforce directory boundaries rather than exposing raw path handling throughout the codebase.
- Applying least-privilege principles to the processes performing synchronization so that even misdirected writes have limited impact on the system.
How teams detect issues like this
Detection generally relies on identifying unsafe path handling and write operations in code and configurations.
Useful strategies include:
- Static analysis rules that flag uses of path-join and file-write APIs receiving data from untrusted sources without normalization or boundary checks.
- Code review guidelines that require verification of directory confinement around any logic performing filesystem writes from remotely supplied paths.
- Policy checks that ensure sync or backup tooling uses whitelisting or root-lock mechanisms for target directories.
- Optional use of automated security scanners to highlight instances where traversal sequences in user-controlled input can reach filesystem APIs.
Detection generally relies on identifying unsafe path handling and write operations in code and configurations.
Useful strategies include:
- Static analysis rules that flag uses of path-join and file-write APIs receiving data from untrusted sources without normalization or boundary checks.
- Code review guidelines that require verification of directory confinement around any logic performing filesystem writes from remotely supplied paths.
- Policy checks that ensure sync or backup tooling uses whitelisting or root-lock mechanisms for target directories.
- Optional use of automated security scanners to highlight instances where traversal sequences in user-controlled input can reach filesystem APIs.
