CVE-2026-119288 in Zuke
Summary
by MITRE • 10/30/2026
Zuke is a code-first, strongly typed build automation system for Deno. Prior to 1.51.0, @zuke/core launches resolved Windows .cmd and .bat shims by prepending cmd /c, causing cmd.exe to reparse a command line assembled with C-runtime quoting rules. A build running on Windows that resolves a tool from node_modules/.bin and passes attacker-influenced text containing an unquoted &, |, or ^ metacharacter can execute an additional attacker-chosen command in the build's context with access to its credentials. POSIX platforms are not affected. This issue is fixed in version 1.51.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Zuke prior to version 1.51.0 represents a critical security flaw rooted in improper command line construction and shell injection on Windows operating systems. As a code-first, strongly typed build automation system for Deno, Zuke is designed to streamline development workflows by managing dependencies and executing build tasks. However, the underlying mechanism used to invoke external tools, specifically those resolved from node_modules/.bin directories containing .cmd or .bat shims, introduces significant risk when user-supplied input is processed without adequate sanitization. The core technical flaw lies in how Zuke constructs the command line for execution on Windows platforms. Instead of directly invoking the executable with arguments passed as distinct parameters, the system prepends cmd /c to a string that combines the tool path and its arguments. This approach forces the Command Prompt interpreter, cmd.exe, to parse the entire assembled string according C-runtime quoting rules rather than treating each argument individually.
This architectural decision creates an opportunity for command injection attacks when attacker-influenced text is passed as part of the build process. Specifically, if a build script passes unquoted special characters such as ampersands (&), pipes (|), or carets (^) to a tool that resolves through this shim mechanism, these metacharacters are interpreted by cmd.exe not as literal data but as command separators and redirection operators. Consequently, an attacker who can influence the input passed to Zuke tasks can inject arbitrary commands into the execution context of the build process. For instance, inserting an unquoted ampersand allows the injection of a secondary command that executes immediately after the intended tool invocation. This is particularly dangerous because build systems typically operate with elevated privileges or access to sensitive credentials required for deployment and compilation tasks.
The operational impact of this vulnerability is severe, as it effectively grants remote code execution capabilities within the context of the CI/CD pipeline or local development environment running on Windows. An attacker could exploit this flaw to exfiltrate source code, steal authentication tokens stored in environment variables, install backdoors, or disrupt the build process entirely. The severity is amplified by the fact that many developers and automated systems trust the inputs provided during builds without rigorous validation, assuming they are benign configuration parameters. It is important to note that POSIX platforms such as Linux and macOS are not affected by this specific vulnerability because their shell interpreters handle argument passing differently, typically respecting quoted strings more strictly or using different execution models that do involve the same cmd.exe parsing behavior.
To mitigate this risk, organizations must immediately upgrade Zuke to version 1.51.0 or later, where the issue has been resolved by correcting how command lines are constructed and executed. In environments where upgrading is not immediately feasible, defensive coding practices should be implemented within custom build scripts. This includes strictly validating all inputs passed to external tools against a whitelist of allowed characters and ensuring that any special shell metacharacters are properly escaped or quoted before being concatenated into command strings. Additionally, developers should avoid using .cmd shims for critical security-sensitive operations on Windows where possible, opting instead for direct executable calls with explicit argument arrays if the underlying tool supports it. This vulnerability is categorized under CWE-78 Improper Neutralization of Special Elements used in an OS Command and aligns with MITRE ATT&CK technique T1059 Command and Scripting Interpreter, highlighting the importance of secure input handling in build automation tools to prevent unauthorized command execution.