Skip to main content

@zuke/cli EUVDEUVD-2026-114137

| CVE-2026-119291 MEDIUM
Improper Link Resolution Before File Access (CWE-59)
2026-10-30 GitHub_M
5.5
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Publish repo/template with symlink at scaffold name
  2. Delivery
    Victim clones untrusted repository
  3. Exploit
    Victim runs zuke setup or zuke import
  4. Execution
    Tool follows link and writes outside target directory
  5. Impact
    Overwrite file or (with --force) drop executable launcher as victim

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Symlink resolution safety
Exploitation Conditions

Requires the victim to run zuke setup or zuke import (< 1.4.0) inside a directory whose contents come from an untrusted source - a cloned repository, downloaded template, or archive - in which the attacker has planted a symbolic link at one of the scaffolded names: .gitignore, deno.json, .mcp.json, zuke.ts, zuke, zuke.ps1, or zuke.json. The .gitignore read-rewrite path needs no flag; writing a launcher at the link's target and making it executable requires the --force flag; the import read-side triggers when it probes for source files by name and parses link-target content into the generated build file. Limiting factors that reduce realistic risk: the attacker must first get untrusted content onto the victim's disk (local vector), the victim must actively invoke the tool (user interaction), impact is bounded by the invoking user's permissions, and only versions below 1.4.0 are affected. Hard links are not detected by the probe but git cannot check them out, keeping them outside the threat.

Impact

This is a genuine but moderate-priority issue, not a drop-everything emergency. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N, base 5.5 Medium) is self-consistent and matches the described mechanism: exploitation is local (the malicious symlink must already be on disk via an untrusted repo/template/archive) and requires the victim to actively run zuke setup or zuke import (UI:R), yielding high integrity impact (arbitrary file overwrite with the invoking user's permissions) but no direct confidentiality or availability loss. No EPSS score was provided, the CVE is not listed in CISA KEV, and no public exploit code was identified - the supplied references are the GHSA advisory, PR #542, the fix commit, and the 1.4.0 release tag (patch artifacts), not a PoC. SSVC-style reasoning agrees with the vendor's this_month decision label: the flaw is not automatable (it depends on social-engineering a victim into cloning attacker content and running the tool) and technical impact is partial rather than total system compromise. One cross-source conflict: the input Tags include 'Information Disclosure', yet the CVSS vector sets C:N and the mechanism is fundamentally file overwrite (integrity); treat the disclosure framing with caution - the import read-side can incorporate link-target content into a generated build file, but that is indirect and not reflected in the scored confidentiality impact.

Exploit ScenarioDerived

An attacker publishes a repository, template, or archive containing a symbolic link placed at one of the scaffold names zuke writes (e.g. .gitignore). A victim clones it and runs zuke setup inside it; zuke probes the name with lstat but then follows the link, rewriting a file outside the cloned directory with the victim's permissions - and under --force, writing and marking executable a launcher at the link's target. No public exploit code was identified at time of analysis, but exploitation requires only local untrusted content plus the victim running the normal setup/import command.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 30, 2026

Symbolic-link following in Zuke CLI (@zuke/cli prior to 1.4.0) allows a repository, template, or archive supplied by an untrusted party to redirect the scaffolder's writes outside the selected directory, with the invoking user's permissions. Running zuke setup in such a directory lets a planted symlink at .gitignore be read through and rewritten with no flag required, and with --force the launcher is written at the link's target and made executable; zuke import additionally reads link-target content and parses it into the generated build file, giving a confidentiality-exposure angle. The vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N (5.5), reflecting that the attacker must first place content on disk and the victim must actively run the tool, and impact is capped by the invoking user's privileges; no public exploit was identified at time of analysis and there is no CISA KEV entry, so this is a moderate-priority item to address this month rather than an emergency.

RemediationAI

Upgrade @zuke/cli to version 1.4.0 or later, which is the vendor-released patch; it refuses a symbolic link at any name the scaffolder is about to write, naming the offending file and what to do about it, and applies the same refusal to the files that zuke import reads. Release notes are at https://github.com/zuke-build/zuke/releases/tag/cli-v1.4.0, the advisory at https://github.com/zuke-build/zuke/security/advisories/GHSA-hc8w-3fgv-22pw, and the fix landed via https://github.com/zuke-build/zuke/pull/542 (commit 4257b0bc5ef5e387a44f913349646d4baccd1654). If upgrading is not immediately possible, the vendor's stated workaround is to inspect an untrusted checkout for symbolic links at .gitignore, deno.json, .mcp.json, zuke.ts, zuke, zuke.ps1 and zuke.json before running setup inside it, for example with find . -maxdepth 1 -type l from the repository root; treat any such link as hostile and remove or replace it. The vendor notes the following trade-offs and gaps: the check is not atomic, so a link planted between the check and the write is still followed (closing that would require an open-without-following primitive Deno does not expose and already presumes local code execution); hard links cannot be detected by any probe, though git cannot check one out; and a directory named explicitly with --dir is still the caller's responsibility to vet.

Affected VersionsENISA

zuke < 1.4.0

Affected Packages

euvd zuke fix: 1.4.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw is a classic CWE-59 link-following problem in a Deno-based build automation tool. Zuke's scaffolder inspects each name it is about to write using lstat, which reports on the symbolic link itself rather than the file it resolves to, but the subsequent read, write, and permission-change operations all traverse the link. An attacker who controls the layout of a cloned repository, downloaded template, or archive can therefore place a symlink at one of the scaffolded names - .gitignore, deno.json, .mcp.json, zuke.ts, zuke, zuke.ps1, or zuke.json - and have the write land on an arbitrary path the invoking user can reach. The .gitignore path is the most exposed because setup reads an existing file and rewrites it with the state directory appended, so no flag is needed; --force extends the primitive to writing and chmod-ing the launcher at the link target, so a file later sourced or executed can carry repository-chosen content. On the import side, the same probe-then-read pattern means source files probed by name can be read through a link and their content folded into the generated build file. The 1.4.0 fix refuses a symlink at any name the scaffolder writes before anything is written, and extends the same refusal to the files import reads. Documented residuals: hard links cannot be distinguished by any probe (git cannot check one out, keeping it outside this threat model), every name is checked before any write so a link planted in between check and write is still followed, and the directory named via --dir remains the caller's responsibility.

Know when Zuke gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 5.5 MEDIUM
AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
vuln.today AI 5.5 MEDIUM

Attacker-supplied content must be local and the victim must run the tool, so AV:L/UI:R; no auth needed (PR:N); arbitrary file overwrite gives I:H, with C:N/A:N matching the overwrite-centric mechanism.

3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
4.0 AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Local
Attack Complexity
Low
Privileges Required
None
User Interaction
Required
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

Lifecycle Timeline

1
Patch available
Oct 30, 2026 - 17:02 EUVD

DescriptionCVE.org

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.

Threat Intelligence Overview

EPSS Score
0.1%
Top 96% exploitable
Prevalence
Low
niche code-first build tool for the Deno runtime, limited footprint
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact· derived
Medium

Priority Score

28
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +28
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy