GHSA-FHGH-WQ4Q-R37X: Remote Code Execution via Sigstore Signature Verification Bypass in uniget CLI

The uniget CLI is a package management and download tool written in Go that retrieves tools and applications from various sources. To determine how to fetch and check the status of local binaries, the utility relies on a central metadata catalog (metadata.json). This metadata structure contains specialized testing parameters, including version-checking directives executed directly on the host operating system.

To prevent the execution of untrusted or modified instructions, the system relies on Sigstore cryptographic signatures to validate the catalog's integrity. Under normal operation, the application must confirm the authenticity of the metadata using the corresponding signature bundle (metadata.json.sigstore.json) before loading any configurations. This validation acts as the primary gate to prevent malicious command execution through untrusted package catalog files.

In version 0.27.4, developers introduced a logical error that disabled this verification loop under default configurations. This regression allowed the application to load unverified catalog files without raising warnings or execution errors. If an attacker is capable of local file system modification, cache injection, or adversary-in-the-middle manipulation, they can inject malicious instructions into the command-line executor.

The vulnerability stems from a logical negation error within the verification gate configuration checks. In version 0.27.1, introduced to address an injection vector, the application checked Sigstore signatures unconditionally. Developers subsequently introduced the UNIGET_IGNORE_METADATA_SIGNATURE environment variable to permit debugging or offline usage without checking cryptographic signatures.

Initially, the safety gate verified signatures if the environment variable was not set to "true". In commit b68a27d5 (released in version 0.27.4), developers altered the conditional branch to accept any non-empty value. However, the logical negation operator was omitted during this refactoring process.

The resulting conditional statement checked if the length of the environment variable was greater than zero. If the variable was empty or absent, the verification code path was bypassed entirely. Consequently, the application failed to call the underlying VerifySigstoreBundle function unless the user explicitly defined the environment variable intended to disable the check.

The logic inversion is located in two distinct code paths within the application. The primary gate resides in internal/config/update.go inside the LoadMetadata function, which determines whether to invoke the verification routine.

// Vulnerable logic in v0.27.4 through v0.28.8
func (c *Config) LoadMetadata(filename string) (loadedTools *tool.Tools, err error) {
    // The signature check ONLY executes if the IGNORE environment variable is set.
    if len(os.Getenv("UNIGET_IGNORE_METADATA_SIGNATURE")) > 0 {
        _, err = security.VerifySigstoreBundle(
            filename,
            filename+".sigstore.json",
            // ... additional signature validation parameters
        )
        if err != nil {
            return nil, fmt.Errorf("error verifying sigstore bundle for metadata: %s", err)
        }
    }
    loadedTools, err = tool.LoadFromFile(filename)

A matching logic error exists in cmd/uniget/main.go within the re-download decision flow. The application evaluates whether a missing .sigstore.json signature bundle should trigger a fresh metadata download.

// Vulnerable download decision logic
if !myos.FileExists(configuration.GetMetadataFile()) ||
    configuration.AutoUpdate ||
    (len(os.Getenv("UNIGET_IGNORE_METADATA_SIGNATURE")) > 0 &&
        !myos.FileExists(configuration.GetMetadataFile()+".sigstore.json")) {

This check prevents uniget from recognizing a missing signature file as an error condition. In a default state, the execution bypasses download routines for missing signature files, rendering the overall cryptographic defense mechanism inactive.

An attacker can exploit this logic inversion to trigger remote code execution by replacing or poisoning the local metadata.json catalog file. When the target user initiates a tool version check, the CLI reads the metadata configuration and executes the code block defined under the check parameter.

The primary command injection sink is located within the RunVersionCheck function of the tool module:

// pkg/tool/tool.go
func (tool *Tool) RunVersionCheck() (string, error) {
    logging.Tracef("Running version check for %s: %s", tool.Name, tool.Check)
    cmd := exec.Command("/bin/bash", "-c", tool.Check+" | tr -d '\\n'")

Because the input to the /bin/bash system executor is derived directly from the unverified JSON structure, an attacker can insert a shell command inside the check attribute of any tool definition. When the victim executes commands such as uniget version <tool_name>, the shell command executes with the permissions of the local user.

This exploitation chain does not require cryptographic keys or signature generation because the target binary never calls the verification sequence.

The impact of this logic bypass is high. Because the security gate intended to prevent arbitrary code execution was completely disabled in default installations, the safety of the application rested entirely on the security of the host cache and metadata distribution channels.

If an attacker compromises the distribution repository, hijacks metadata mirrors, or alters local cache files via a separate lower-privilege process, they can gain full shell control. The commands are processed within /bin/bash under the security context of the active terminal session, allowing the attacker to read, modify, or delete files, perform privilege escalation, or establish persistent remote access.

The vulnerability is tracked under GitHub Security Advisory GHSA-FHGH-WQ4Q-R37X with a CVSS v3.1 score of 7.8, reflecting the high potential impact to system confidentiality, integrity, and availability.

To resolve the vulnerability, update the uniget installation to version 0.28.9 or higher. The patch reverses the evaluation check in both update.go and main.go, changing the logic from checking for a non-empty string to verifying that the string is empty.

// Patched logic in v0.28.9
if len(os.Getenv("UNIGET_IGNORE_METADATA_SIGNATURE")) == 0 {
    // Verification now executes under default configuration states

For systems where the application cannot be immediately updated, administrators can apply a manual workaround. Setting the UNIGET_IGNORE_METADATA_SIGNATURE environment variable to any non-empty value (such as 1) will force vulnerable versions of the binary to trigger the signature checking sequence.

> [!WARNING] > This workaround is a temporary measure designed to trigger verification on affected binaries. If the variable remains set after upgrading to version 0.28.9 or later, the patched binary will skip signature verification as originally intended.