Back to skill

Security audit

Storacha Upload

Security checks for vulnerabilities and agentic risk

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.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches 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

Content
View full analysis

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
text

### 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
View 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

Content
View full analysis

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 user@example.com"), 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 user@example.com

Replace user@example.com with the actual email the user gave you.

text

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
View 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.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (6)

Vague Triggers

High
Category
Not specified by scanner
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.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
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.

Content

No source excerpt is available for this finding.

Behavior Manipulation

Medium
Category
Prompt Injection
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.

Content

Scanner excerpt · SKILL.md (reported line 40)May include surrounding context.

md
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.

Vague Triggers

Medium
Category
Not specified by scanner
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.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium
Category
Excessive Agency
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.

Content

Scanner excerpt · SKILL.md (reported line 213)May include surrounding context.

md
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

Context-Inappropriate Capability

Medium
Category
Not specified by scanner
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.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.