Zarf has a Path Traversal via Malicious Package Metadata.Name — Arbitrary File Write

The vulnerability lies in how Zarf constructs output file paths when inspecting packages. Specifically, the Metadata.Name field, which is attacker-controlled data read from the package archive, is used to build the output file path. While this field undergoes regex validation during package creation (^[a-z0-9][a-z0-9\-]*$), it doesn't prevent an attacker from crafting a malicious package that, when inspected, leads to the creation of files in unexpected locations. An attacker could leverage this to read sensitive configuration files, source code, or other data from the system running Zarf. The blast radius is limited to the system executing the zarf command, but the potential for data exposure is significant.

Developers and DevOps engineers who utilize Zarf for package management and inspection are at risk. Specifically, those who routinely inspect packages from untrusted sources or those who have not implemented robust package signing policies are particularly vulnerable. Shared hosting environments where multiple users share the same Zarf installation could also be affected.

• linux / server:

find / -type f -name '*Metadata.Name*' -print

• go / supply-chain: Inspect Go module dependencies for suspicious packages or versions. • generic web: Monitor Zarf logs for unusual file creation paths during package inspection. Look for patterns that deviate from expected behavior.

1. 2026-04-14Disclosure

   disclosure

1. Gereserveerd2026-04-09
2. Gepubliceerd2026-04-14
3. Gewijzigd2026-04-15
4. EPSS bijgewerkt2026-04-22

The primary mitigation is to upgrade Zarf to version 0.74.2 or later, which includes the fix for this vulnerability. If upgrading is not immediately feasible, a temporary workaround is to avoid inspecting unsigned packages. This significantly reduces the attack surface by preventing the inspection of potentially malicious artifacts. Consider implementing stricter package signing policies to ensure that only trusted packages are inspected. There are no specific WAF or proxy rules that directly address this vulnerability, as it's a local command execution issue. Detection signatures are challenging to create without specific file path patterns, but monitoring for unusual file creation activity during package inspection could be beneficial.