CVE-2026-40090

Workarounds

Avoid inspecting unsigned packages

Description

The package inspect sbom and package inspect documentation subcommands construct output file paths by joining a user-controlled output directory with the package's Metadata.Name field, which is attacker-controlled data read from the package archive. The Metadata.Name field is validated against a regex on create, ^[a-z0-9][a-z0-9\-]*$, however a malicious user could unarchive a package to change the .Metadata.Name field and the files inside the SBOMS.tar. This would lead to arbitrary file write in a location of the attackers choosing.

Neither location sanitizes or validates the package name before using it in the file path.

SBOM inspection:

outputPath := filepath.Join(o.outputDir, pkgLayout.Pkg.Metadata.Name)
err = pkgLayout.GetSBOM(ctx, outputPath)

Documentation inspection (line 1219):

outputPath := filepath.Join(o.outputDir, fmt.Sprintf("%s-documentation", pkgLayout.Pkg.Metadata.Name))
return pkgLayout.GetDocumentation(ctx, outputPath, o.keys)

pkgLayout.Pkg.Metadata.Name is read directly from the untrusted package's zarf.yaml manifest. An attacker can craft a malicious Zarf package where Metadata.Name contains path traversal sequences or root paths such as ../../etc/cron.d/malicious or /home/user/.ssh/authorized_keys.

CVSS Explainations

Attack Vector

Verdict: Network
A malicious package could be published to OCI and inspected directly with zarf package inspect sbom oci://<bad-package>

Attack Complexity

Verdict: Low
It is not complicated to make and publish a malicious package. The Attacker only needs to edit the zarf.yaml and sboms.tar then edit the checksums.

Privileges Required

Verdict: None
The attacker is relying on the runner of zarf package inspect sbom|documentation and needs no other privileges.

User Interaction

Verdict: Required
The user must run the inspect command

Scope

Verdict: Unchanged
The vulnerability operates entirely within the permissions of the user running zarf package inspect. The file write can't escape the privilege boundary of that user

Confidentiality

Verdict: None
This is an arbitrary file write vulnerability. The attacker can place or overwrite files on the filesystem but the vulnerability does not provide any mechanism to read or exfiltrate data from the target system.

Integrity

Verdict: High
The attacker controls both the file path (via Metadata.Name) and the file content (via the SBOM or documentation files inside the archive). This allows writing attacker-controlled content to arbitrary locations on the filesystem, limited only by the permissions of the user running the inspect command. Realistic exploitation includes writing SSH authorized_keys, cron jobs, or shell profiles.

Availability

Verdict: Low
The vulnerability does not directly target service availability. However, an attacker could overwrite files that cause system disruption.

This vulnerability impacts users of zarf package inspect sbom or zarf package inspect documentation on untrusted packages.

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

CVE-2026-40090 has a CVSS score of 7.1 (High). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.74.2); upgrading removes the vulnerable code path.

Kodem intelligence

#4793, now fixed in version v0.74.2

1. What is CVE-2026-40090? CVE-2026-40090 is a high-severity path traversal vulnerability in github.com/zarf-dev/zarf (go), affecting versions >= 0.23.0, < 0.74.2. It is fixed in 0.74.2. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
2. How severe is CVE-2026-40090? CVE-2026-40090 has a CVSS score of 7.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/zarf-dev/zarf are affected by CVE-2026-40090? github.com/zarf-dev/zarf (go) versions >= 0.23.0, < 0.74.2 is affected.
4. Is there a fix for CVE-2026-40090? Yes. CVE-2026-40090 is fixed in 0.74.2. Upgrade to this version or later.
5. Is CVE-2026-40090 exploitable, and should I be worried? Whether CVE-2026-40090 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-40090 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-40090? Upgrade github.com/zarf-dev/zarf to 0.74.2 or later.