Storacha Upload

• Outcome: Review
• Latest audit: Sep 11, 2026 · 12:37 AM UTC
• Version: 1.3.1

Overview

This Storacha/IPFS skill matches its stated purpose, but it gives the agent too much silent authority over public uploads, deletion, space changes, global installation, and broad delegations.

Install only if you are comfortable with an agent managing your Storacha account. Confirm every upload, deletion, space switch, and delegation yourself; do not upload secrets or sensitive personal files unless encrypted first; avoid full-admin delegations unless you fully trust the recipient; and prefer a pinned, reviewed Storacha CLI installation.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:81
• Finding: Unpinned Global Installation of a Third-Party CLI Package## Vulnerability Details **File Location**: `SKILL.md:81-86`; repeated at `SKILL.md:106-111, 401, 415` and `README.md:30, 38, 53` **Vulnerability Type**: Unpinned third-party dependency installed globally **Risk Level**: Medium **Vulnerable Code**: ```markdown If `storacha` is not found, install it: ```bash npm install -g @storacha/cli ``` ``` ### Technical Analysis The skill instructs the agent to install the latest available version of `@storacha/cli` from the npm registry. It does not specify an exact reviewed version, verify package integrity or provenance, use a lockfile, or request approval before performing a global installation. A global npm installation can execute package installation logic with the privileges of the account running the agent. The effective package contents can also change after this skill has been audited because npm resolves the command to the registry version current at execution time. The package name is consistent with the declared Storacha service, and the audited project contains no evidence that the current package is malicious. The risk arises from the unpinned and globally mutable dependency channel. ### Attack Path 1. An attacker compromises the npm package, a maintainer account, or the associated publication process. 2. The attacker publishes a malicious release under the expected `@storacha/cli` package name. 3. The skill detects that `storacha` is unavailable and executes `npm install -g @storacha/cli`. 4. npm retrieves the newly published package rather than a previously reviewed version. 5. Malicious package code or lifecycle scripts execute with the privileges of the agent user. 6. The compromised package can subsequently intercept files uploaded through the CLI or access authorization material available to that user. ### Impact Assessment Successful exploitation could execute arbitrary code as the account running npm, modify globally installed Node.js packages o ...[truncated 347 chars]
• Remediation: ## Remediation Suggestions - Pin the CLI to an exact reviewed version, for example `@storacha/cli@X.Y.Z`. - Record and verify the expected package integrity hash and npm provenance before installation. - Prefer a project-local dependency with a lockfile over a global installation. - Require explicit user or administrator approval before installing software. - Run installation and the CLI under a dedicated, unprivileged account. - Disable npm lifecycle scripts with `--ignore-scripts` if the reviewed CLI remains functional without them. - Maintain an allowlist of approved package names, versions, publishers, and integrity values. - Update every repeated installation instruction in `SKILL.md` and `README.md` so users are not directed back to the unsafe command.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:131
• Finding: User-Controlled Values Are Inserted into Shell Command Templates Without Robust Validation## Vulnerability Details **File Location**: `SKILL.md:131-145`; related command templates at `SKILL.md:202-209, 271-280, 318-325, 359-368` **Vulnerability Type**: Potential command and argument injection **Risk Level**: Medium **Vulnerable Code**: ```markdown If the user already provided their email (e.g. "login to storacha, my email is [e-mail]"), skip asking and go straight to Step B. **DO NOT proceed until you have the user's email address.** **Step B — Run login:** **IMPORTANT: The `storacha login` command is NOT interactive when you pass the email as an argument. You MUST run it directly. Do NOT tell the user to run it manually. Do NOT say you can't run it. YOU run it.** ```bash storacha login [e-mail] ``` Replace `[e-mail]` with the actual email the user gave you. ``` Additional affected templates include: ```bash storacha up /path/to/file storacha rm CID storacha rm CID --shards storacha space use "SpaceName" ``` ### Technical Analysis The skill directs an agent to replace command placeholders with user-provided emails, file paths, CIDs, and space names. It does not require strict format validation, argument-array execution, shell escaping, option termination, or path authorization. If an implementation constructs a shell command string from these templates, shell metacharacters in a supplied value may be interpreted as command syntax rather than data. Even where shell metacharacters are escaped, values beginning with `-` may be interpreted as Storacha options unless the command supports and uses an option terminator. Quoting the space name reduces ordinary word splitting but is not a safe substitute for argument-array execution if the command itself is generated through textual interpolation. File paths present an additional authorization concern: the instructions say to use a referenced path directly without requiring canonicalization or verifying that the user is per ...[truncated 1713 chars]
• Remediation: ## Remediation Suggestions - Invoke the CLI through a subprocess API with an explicit argument array; never concatenate user input into a shell command string. - Validate email addresses against a conservative length-limited format and reject control characters, newlines, and shell metacharacters. - Parse and validate CIDs with a maintained CID library before passing them to the CLI. - Restrict space names to a documented safe character set and length. - Canonicalize referenced file paths and enforce an allowlisted upload directory or explicit attachment boundary. - Reject symbolic links or verify their resolved targets before uploading. - Use `--` before path operands where supported to prevent option injection. - Require explicit confirmation that identifies the target CID and active space before `storacha rm`, especially when `--shards` is requested. - Require explicit confirmation before creating broad UCAN delegations. - Update the skill text to state these validation and execution requirements for every command accepting user-controlled values.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (6)

Vague Triggers

High

• Confidence: 96% confidence
• Finding: The manifest uses a very large set of broad trigger phrases such as 'share this file', 'open this CID', 'get me the link', and generic storage/authentication language that can overlap with ordinary conversation. This increases the chance the skill is auto-selected in contexts where the user did not intend public IPFS upload or account-changing actions, which is especially risky because uploads are public and potentially permanent.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The README promotes uploading, sharing, retrieving, and deleting IPFS/Storacha content but does not warn users that IPFS links may expose data publicly, that content-addressed storage can be effectively irreversible once replicated, or that deletion from Storacha may not remove already-shared gateway copies. In a skill explicitly designed for decentralized storage and sharing, omission of these warnings can mislead users into exposing sensitive files or assuming deletion guarantees privacy.

Behavior Manipulation

Medium

• Category: Prompt Injection

Content

Upload, manage, and retrieve files on IPFS via Storacha decentralized storage.

> **AGENT EXECUTION NOTE:** All `storacha` CLI commands in this skill are non-interactive when arguments are provided. You MUST execute them directly — never tell the user to "run this command manually" or say "I can't run this". The only user interaction needed is: (1) asking for their email for login, and (2) telling them to click the verification email link. Everything else you handle silently.

> **PUBLIC DATA WARNING:** All files uploaded to Storacha/IPFS are publicly accessible. Anyone with the CID can retrieve them. Never upload unencrypted sensitive data.

• Confidence: 76% confidence
• Finding: The instruction to 'never tell the user' to run commands manually and to handle everything silently pushes the agent toward concealed action rather than transparent consent. In isolation this is not a direct exploit, but combined with login, upload, deletion, space management, and delegation capabilities it reduces user visibility into security-relevant operations.

Vague Triggers

Medium

• Confidence: 91% confidence
• Finding: The intent-matching table maps casual phrases directly to sensitive actions without enough exclusion criteria or confirmation gates. In particular, phrases like 'delete this', 'get me the link', or 'switch space' could be misinterpreted from ambiguous user requests, leading to unintended uploads, deletions, or sharing of publicly accessible data.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

Then tell the user:
  > "I've set 'SpaceName' as your active storage space."

Handle all of this silently without asking the user to run commands. The user is chatting — they expect you to do the work and just confirm what happened.

### Step 4 — Verify Provider Registration

• Confidence: 90% confidence
• Finding: The skill instructs the agent to silently create spaces, select active spaces, and recover from errors without asking the user. That autonomy can change account state and routing of future uploads without informed consent, making accidental uploads, use of the wrong space, or unexpected account configuration changes more likely.

Context-Inappropriate Capability

Medium

• Confidence: 94% confidence
• Finding: The skill exposes creation of UCAN delegations, including a full-admin `--can '*'` delegation, which materially exceeds basic file upload and retrieval functionality. If invoked carelessly or through prompt confusion, it could grant another principal broad authority over the user's Storacha resources, enabling unauthorized uploads, management actions, or further delegation.

Static analysis

No suspicious patterns detected.