T08 · Insecure Dependencies
- Location
SKILL.md:117- Finding
Unpinned Remote Package Execution Through uvx
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 117-119
Vulnerability Type: Unpinned third-party package execution
Risk Level: MediumVulnerable Code Snippet:
text When shell access is easier than HTTP: `uvx openshorts process <url> --wait`, `openshorts clips <job_id>`, `openshorts publish <job_id> 0 --platforms tiktok`. Auth via `OPENSHORTS_API_KEY` / `OPENSHORTS_API_URL` env vars.Technical Analysis
The documented
uvx openshortscommand can retrieve and execute the currently resolved version of theopenshortspackage without pinning a reviewed version or verifying package integrity. This creates a supply-chain trust boundary in which the code executed at invocation time may differ from the code reviewed when the Skill was audited.The same instructions state that authentication is supplied through the
OPENSHORTS_API_KEYenvironment variable. A package executed byuvxruns with the invoking user's privileges and can normally access inherited environment variables. If the package distribution, maintainer account, or dependency resolution process is compromised, malicious package code could read this API key, access local files available to the user, and execute arbitrary commands.The remote video-processing behavior itself is disclosed and necessary for the Skill's hosted functionality. However, dynamically executing an unpinned package is not required because the Skill also supports direct REST and MCP access.
Attack Path
- An attacker compromises the package publisher, package registry account, or a dependency selected by an unpinned package release.
- The attacker publishes a malicious version that retains expected CLI behavior while adding credential theft or arbitrary command execution.
- A user or agent follows the Skill's documented
uvx openshorts process ...shortcut. uvxresolves, downloads, and executes the malicious package version ...[truncated 791 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the CLI to an explicitly reviewed version, for example by documenting
uvx openshorts==<reviewed-version> ...if the package manager supports that syntax. - Use a lockfile or package-manager mechanism that verifies cryptographic hashes for the package and its transitive dependencies.
- Document the authoritative package registry and publisher identity so users can verify that they are installing the intended package.
- Prefer the documented REST or MCP interfaces where feasible, as they avoid dynamically executing a newly resolved local package.
- Run the CLI with the minimum necessary environment. Expose only
OPENSHORTS_API_KEYwhen required and remove unrelated secrets from the child process. - Use a restricted, short-lived, and revocable API credential where supported. Rotate the key immediately if package compromise is suspected.
- Consider executing the CLI in a sandbox or container with limited filesystem and network access.
- Pin the CLI to an explicitly reviewed version, for example by documenting
