Executive brief
The uniget CLI, a tool installer that downloads and runs binaries from a central catalog, has a critical logic error in its metadata verification code. The condition that enables signature checking on the tool catalog is inverted, causing signatures to be validated only when an environment variable named "ignore metadata signature" is set—the opposite of the intended behavior. This allows an attacker to poison the tool catalog (via a compromised registry, network tampering, or cached file) and execute arbitrary commands as the user running uniget, completely bypassing the security control added in a prior patch.
Technical details
The vulnerability is a logic inversion in the metadata signature verification gate in uniget/internal/config/update.go at line 81. The code checks `if len(os.Getenv("UNIGET_IGNORE_METADATA_SIGNATURE")) > 0` before calling `VerifySigstoreBundle()`, which means verification only runs when the ignore variable is set (non-empty). This inverted condition resulted from a commit (b68a27d5) that intended to accept any truthy value instead of the literal string "true", but accidentally dropped the negation operator in the rewrite. The same flipped logic appears in cmd/uniget/main.go:104 for the metadata re-download decision. Tool metadata populates the `Tool.Check` field, which is executed via `/bin/bash -c` in RunVersionCheck() without re-validation. An attacker with control over the metadata layer (compromised OCI registry, network interception, or poisoned local cache) can inject malicious shell commands that execute with the privileges of the user running uniget. The patch from v0.27.1 (which added sigstore verification) has been non-functional since v0.27.4.
Affected products
- uniget-org cli >=0.27.4, <0.28.9
Timeline
- 2026-08-17: disclosed: Published to GitHub Advisory Database
- 2026-08-17: patched: Fixed in version 0.28.9