zuke setup and zuke import follow symbolic links planted at scaffold names, allowing writes outside the target directory
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.4.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Zuke, a code-first build automation system for Deno, is affected through its @zuke/cli setup and import commands. An attacker who supplies a malicious repository, template, or archive containing a symbolic link can trick these commands into overwriting files outside the chosen directory or reading and embedding content from outside it, using the permissions of the user running the command.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- zuke-build zuke
fixed in 1.4.0