T03 · Remote Payload Retrieval and Execution
Error
- Location
- SKILL.md:61
- Finding
- Unverified Remote Installer Downloaded and Executed Directly## Vulnerability Details **File Location**: `SKILL.md`, lines 61–65 **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High ### Vulnerable Code ```bash curl -fsSL https://cli.oomol.com/install.sh | bash # macOS / Linux ``` ```powershell irm https://cli.oomol.com/install.ps1 | iex # Windows PowerShell ``` ### Technical Analysis Both installation commands retrieve mutable content from an external server and immediately execute it in a local shell. Neither command pins a version, verifies a cryptographic checksum or signature, nor gives the user an opportunity to inspect the downloaded script before execution. HTTPS protects the connection in transit under normal circumstances, but it does not establish that the script currently hosted at the URL is the same script that was reviewed with this Skill. Compromise of the hosting infrastructure, DNS or certificate ecosystem, deployment pipeline, or vendor account could replace the installer after publication. The next installation would then execute the replacement payload. The instructions are conditional on the `oo` command being unavailable, which reduces exposure, but they still direct execution of code beyond the audited project. Installing a general-purpose CLI is also broader than the minimum privileges required for an individual Speedtest Tracker query. The Skill declares `Bash(oo *)` as its allowed tool surface, so direct installer execution may be blocked where that restriction is strictly enforced; however, the documented setup path remains unsafe for users or environments that follow it outside that enforcement boundary. The Windows command has the same underlying problem: `Invoke-RestMethod` retrieves the response, and `Invoke-Expression` executes it without validation. No evidence in the reviewed file proves that the current OOMOL installer is malicious. The confirmed vulnerability is the unauthenticated-at-the-artifact-level ...[truncated 1958 chars]
- Remediation
- ## Remediation Suggestions - Do not pipe network responses directly into a shell or `Invoke-Expression`. - Pin installation instructions to a specific, immutable CLI release rather than mutable `install.sh` and `install.ps1` endpoints. - Download the installer or release artifact to a local file first, then verify a vendor-published SHA-256 or stronger checksum before execution. - Prefer cryptographic signature verification using a pinned and independently distributed vendor signing key. A checksum hosted only beside the mutable artifact does not adequately protect against compromise of the same server. - Display the resolved version, source URL, checksum, destination paths, and expected privilege requirements before installation. - Require explicit user approval before installing software. An agent should report that the CLI is missing and provide verified manual instructions rather than automatically running an installer. - Execute installation with ordinary user privileges and avoid administrator or root execution unless a reviewed step demonstrably requires it. - Where available, use a trusted package manager with signed metadata and version pinning. - Retain and enforce the `Bash(oo *)` restriction so the Skill cannot invoke arbitrary shell commands, installers, or package managers. - A safer Unix workflow would download a versioned artifact, compare its digest against a pinned value, and execute it only after successful verification. Apply an equivalent download-and-signature-verification workflow on Windows instead of `irm | iex`.