CVE-2026-119291 in Zuke
Summary
by MITRE • 10/30/2026
Zuke is a code-first, strongly typed build automation system for Deno. Prior to 1.4.0, @zuke/cli uses lstat to inspect scaffold names but then performs link-following reads, writes, and permission changes in zuke setup and zuke import. An attacker who supplies an untrusted cloned repository, template, or archive with a symbolic link at a scaffolded name can cause setup to overwrite a target outside the selected directory with the invoking user's permissions. The .gitignore path requires no flag, while --force permits a linked launcher target to be written and made executable; import can also read link-target content and incorporate it into the generated build file. This issue is fixed in version 1.4.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Zuke versions prior to 1.4.0 represents a critical path traversal and symbolic link following flaw within its code-first, strongly typed build automation system for Deno. The core of the issue lies in an inconsistent handling of file system operations during the setup and import processes. Specifically, while the initial inspection phase correctly utilizes lstat to examine scaffold names without resolving symbolic links, subsequent operational phases such as zuke setup and zuke import fail to maintain this restriction. Instead, these commands perform link-following reads, writes, and permission changes. This discrepancy creates a race condition-like scenario where an attacker can exploit the gap between metadata inspection and actual file manipulation by supplying untrusted inputs containing symbolic links that point outside the intended target directory.
An adversary who provides an untrusted cloned repository, template, or archive with carefully crafted symbolic links at scaffolded names can leverage this flaw to overwrite arbitrary files on the host system. Because the write operations follow the symlink, data is written not to the expected location within the selected project directory but to the absolute path specified by the link target. Crucially, these writes occur using the permissions of the invoking user, which often implies elevated privileges depending on how Zuke is executed in a development or CI/CD environment. This allows for potential arbitrary file write vulnerabilities that can lead to code execution if critical system files or configuration scripts are targeted and overwritten with malicious content.
The impact extends beyond simple overwriting due to specific flags and behaviors within the tool. The .gitignore path processing requires no additional flag, meaning standard ignore patterns do not mitigate this risk during initial setup phases. Furthermore, the --force option explicitly permits a linked launcher target to be written and made executable, significantly increasing the severity by enabling direct code execution capabilities. Additionally, the import functionality can read content from these link targets and incorporate it into the generated build file. This means that even if an attacker cannot directly overwrite critical system files due to permission restrictions on certain paths, they can still inject malicious logic or sensitive data into the project's configuration through the import mechanism, potentially compromising the integrity of subsequent builds.
This vulnerability aligns with CWE-59 Improper Link Resolution Before File Access and CWE-22 Path Traversal: '..' Sequence, as it involves manipulating file system links to access resources outside the intended directory scope. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1036 Masquerading or potentially T1499 Endpoint Denial of Service if used destructively, but more accurately reflects techniques associated with privilege escalation and lateral movement via arbitrary file writes such as those seen in T1552 Unsecured Credentials if sensitive files are read, though the primary vector is unauthorized modification. The exploitation relies on social engineering or supply chain compromise to introduce malicious templates or repositories into the development workflow.
To mitigate this risk, organizations must immediately upgrade Zuke to version 1.4.0 or later where these inconsistencies have been resolved. Until upgrading is possible, developers should enforce strict validation of all external inputs including cloned repositories and archives before running setup or import commands. It is advisable to disable or avoid the use of the --force flag in untrusted environments and to implement sandboxing for build automation tools that process user-supplied templates. Security teams should also audit existing CI/CD pipelines for any usage of Zuke versions prior to 1.4.0 and restrict execution permissions where possible to limit the blast radius of potential file system modifications. Regular scanning of dependencies for known vulnerabilities in build tooling is essential to prevent exploitation through compromised supply chain artifacts.