T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:16- Finding
Unverified Remote Installer Piped Directly into System Shells
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 16–17
Vulnerability Type: Remote payload retrieval and execution
Risk Level: CriticalVulnerable Code
markdown - **macOS / Linux**: `curl -fsSL https://d.officecli.ai/install.sh | bash` - **Windows (PowerShell)**: `irm https://d.officecli.ai/install.ps1 | iex`Technical Analysis
Both installation commands retrieve mutable content from an external domain and execute it immediately. The Unix command sends the HTTP response directly to
bash, while the Windows command passes it to PowerShell'sInvoke-Expression(iex).The instructions provide no version pinning, cryptographic checksum, signature verification, content review step, or immutable release reference. Consequently, the effective code executed during installation may differ from the content available when the Skill was audited. HTTPS protects the connection in transit but does not establish that the server's current payload is trustworthy, immutable, or uncompromised.
This behavior is unnecessary for the Skill's core purpose of guiding financial-model creation. Installing a required CLI may be legitimate, but arbitrary remote code execution is not the minimum privilege or safest installation method needed to obtain that dependency.
Attack Path
- A user or Agent loads the Skill and determines that
officecliis unavailable. - It follows the setup instructions for the operating system.
- The command retrieves a script from
d.officecli.ai. - If the hosting account, web server, DNS path, deployment pipeline, or script itself is compromised, an attacker substitutes malicious shell commands.
bashoriexexecutes the response immediately under the invoking user's account without integrity verification or review.- The payload can then access resources available to that account or download and execute further components.
Impact Assessment
The remote payload obtains arbitrary code execution wi ...[truncated 836 chars]
- A user or Agent loads the Skill and determines that
- Remediation
View remediation
Remediation Suggestions
-
Remove both direct execution pipelines:
- Do not use
curl ... | bash. - Do not use
irm ... | iex.
- Do not use
-
Refer users to a specific, versioned release hosted through the project's official release channel rather than a mutable installer endpoint.
-
Publish cryptographic checksums and preferably signed release artifacts. Require verification before execution. For example:
- Download the artifact as a separate step.
- Verify its SHA-256 digest against a pinned value delivered through a trusted channel.
- Verify a code-signing or detached signature where supported.
- Execute or install it only after successful verification.
-
Pin the documented dependency version so future changes cannot silently alter the audited installation payload.
-
Prefer a trusted package manager with version locking and package-signature verification where available.
-
If an installer script remains necessary, save it locally and instruct the user to inspect it before execution. Document the files, network access, PATH changes, and privileges it requires.
-
State explicitly that installation must run without administrator or root privileges unless a narrowly defined operation genuinely requires elevation. Fail safely rather than requesting broad privilege.
-
Keep the GitHub release fallback version-specific and add checksum or signature verification; merely changing the download host does not eliminate supply-chain risk.
-
