Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The sigstore check on metadata.json is gated on the wrong side of the condition. LoadMetadata in internal/config/update.go:81 verifies the bundle only when UNIGETIGNOREMETADATASIGNATURE is non-empty, so in a normal run, where nobody sets that variable, the signature is never checked. Setting the variable that is named "ignore the signature" is what turns verification on. That matters because metadata.json populates Tool.Check, and pkg/tool/tool.go:250 runs Tool.Check through /bin/bash -c. That is the same sink as CVE-2026-45152, and the signature check added in v0.27.1 to close it is the control that no longer runs. Where it is internal/config/update.go:80-100: cmd/uniget/main.go:102-105 carries the same flipped condition in the decision about whether to re-download metadata: so a cached metadata.json with no .sigstore.json beside it is not refetched either, as long as the variable is unset. LoadMetadata is called from cmd/uniget/main.go:115 in the persistent pre-run, which…
Recommended action: Upgrade to 0.28.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Path Traversal vulnerability in hook filename handling allows attackers to access and manipulate arbitrary files outside the hooks directory via directory escape sequences like passwd. Details File: hooks.go Lines 135-160 Hook filenames are concatenated directly without sanitizing ../ sequences, allowing directory traversal. PoC Step 1: Set cat as editor Step 2: Read /etc/passwd via path traversal Step 3: Output shows file contents <img width="1014" height="178" alt="image" src="https://github.com/user-attachments/assets/0db0fe7e-533b-4d8e-a346-81886ce866ab" /
Recommended action: Upgrade to 0.27.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The uniget CLI has a command injection vulnerability in hooks.go line 199 where strings.Split(editor, " ") naively parses the EDITOR environment variable without respecting shell syntax. An attacker can set EDITOR="/path/to/wrapper && id && echo" which gets split into separate arguments, allowing the wrapper script to execute arbitrary commands like id. This was successfully exploited to execute uid=1000(w4nn4d13), confirming code execution is possible. The vulnerability affects hook editing and breaks configurations with modern editors like VSCode. Vulnerable Code: Location Context: Issue: Naive space-splitting allows injection. EDITOR="script && id && echo" splits into ["script", "&&", "id", "&&", "echo"] enabling command execution. Step to Reproduce Step 1: Create malicious editor wrapper Step 2: Create test hook Step 3: Set injection payload Step 4: Run vulnerable code Step 5: Observe output <img width="1017" height="449" alt="image"…
Recommended action: Upgrade to 0.27.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
I discovered a command injection vulnerability in uniget that allows arbitrary command execution through the metadata loading and version check mechanism. Summary A command injection vulnerability exists in uniget due to unsafe execution of the check field from metadata files using /bin/bash -c. Because the check field is loaded directly from untrusted JSON metadata without validation or sanitization, an attacker can craft malicious metadata that executes arbitrary shell commands on the victim’s system when common uniget operations such as describe, install, update, or inspect are performed. This vulnerability can lead to arbitrary code execution with the privileges of the user running uniget. Details The vulnerable code is located in: tool.go:250 Vulnerable function: The issue occurs because the tool.Check field is populated directly from metadata JSON files without validation. Related structure: Metadata loading uses json.Unmarshal() to populate the Tool struct directly from JSON…
Recommended action: Upgrade to 0.27.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.