T03 · Remote Payload Retrieval and Execution
Error
- Location
- SKILL.md:16
- Finding
- Unverified Remote Installation Script Executed Directly by Shell<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 16 **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Critical ### Vulnerable Code ```bash curl -fsSL https://cli.inference.sh | sh && infsh login ``` ### Technical Analysis The installation instruction downloads mutable content from `https://cli.inference.sh` and immediately pipes it into `sh`. The script is executed before the user can inspect it, pin its version, or verify its authenticity through a signature or independently obtained digest. HTTPS protects the network connection in transit but does not establish that the remotely hosted script is safe. The effective payload can change after this Skill has been reviewed. Compromise of the hosting service, its deployment credentials, domain, or delivery infrastructure could therefore turn this documented installation command into arbitrary code execution. The document claims that the installer only detects the operating system and architecture, downloads a binary, and verifies its SHA-256 checksum. However, the installer is not included in the project, so these claims and the verification implementation cannot be audited. Verification performed by an unauthenticated remote installer also does not protect against compromise of both the installer and its checksum source. Installing a CLI is relevant to the declared video-generation functionality, but granting a mutable remote script unrestricted shell execution is not the minimum privilege necessary. The installer inherits the invoking user's filesystem, process, environment, credential, and network access. Chaining `infsh login` also encourages authentication immediately after executing the unverified program. ### Attack Path 1. An attacker compromises or maliciously modifies `cli.inference.sh`, its hosting account, deployment pipeline, domain configuration, or another component in its delivery chain. 2. The server begins returning an attacker-controlled ...[truncated 1334 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the `curl | sh` installation pattern. 2. Pin the CLI to a specific, immutable release version rather than retrieving a mutable installer endpoint. 3. Separate download, verification, installation, and authentication into distinct commands. 4. Publish expected SHA-256 digests through an independently authenticated, versioned release channel. 5. Require users to verify the downloaded artifact locally before executing or installing it. 6. Prefer cryptographically signed binaries or packages and document signature verification using a pinned public key. 7. Provide platform-specific package-manager instructions where packages can be version-pinned and integrity-checked. 8. Do not initiate `infsh login` in the same command as installation. Users should authenticate only after independently confirming the installed binary's provenance. 9. If an installer remains available, instruct users to download it to a local file, inspect it, verify a pinned digest or signature, and only then execute it with ordinary user privileges. 10. Avoid requesting administrator privileges unless a specific installation destination requires them; provide a user-local installation option by default. A safer workflow should follow this general structure: ```bash # Download a specific release. curl -fSLo infsh "<immutable-versioned-release-url>" # Verify against a trusted, pinned digest before execution. printf '%s %s\n' "<expected-sha256>" "infsh" | sha256sum --check - # Install with user-level permissions, then authenticate separately. install -m 0755 infsh "$HOME/.local/bin/infsh" infsh login ``` ]]>