Back to skill

Security audit

Cannon

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent Cannon documentation, but it deserves review because its setup and examples can expose users to unsafe remote installation and private-key handling during irreversible blockchain operations.

Review this skill before installing if it will be used around funded wallets or production deployments. Prefer isolated development environments, pinned and verified tool installation, hardware or managed signers instead of raw private keys, dry-runs before any real network action, and careful review of package contents before publishing to the on-chain registry or IPFS.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • 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
Findings (3)

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:58
Finding
Remote Foundry Installer Is Downloaded and Executed Without Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:58` **Vulnerability Type**: Remote payload retrieval and immediate shell execution **Risk Level**: Critical ### Vulnerable Code ```bash - **Foundry** (forge, anvil, cast) - `curl -L https://foundry.paradigm.xyz | bash && foundryup` ``` ### Technical Analysis The installation instruction pipes the response from a mutable external URL directly into Bash. The remote content is executed before the user can inspect it, and the instruction provides no release pinning, checksum validation, signature verification, or other integrity control. The `-L` option follows HTTP redirects, meaning the final payload may be served from a different location than the visible URL. Even if the named Foundry domain is legitimate at the time of review, the effective executable content remains outside this package and can change after the skill has been audited. This behavior is not necessary to provide Cannon documentation or deployment assistance. Foundry can instead be installed from a pinned release using a separately downloaded and cryptographically verified artifact. ### Attack Path 1. A user or AI agent follows the prerequisite instruction in `SKILL.md`. 2. The external host, its delivery infrastructure, DNS resolution, or a redirect destination is compromised or begins serving modified content. 3. `curl` downloads the attacker-controlled response. 4. The shell pipeline sends the response directly to Bash without review or integrity verification. 5. The payload executes with the privileges of the user running the command. 6. The payload can inspect or modify accessible files, environment variables, wallet configuration, source code, and local agent data. ### Impact Assessment Successful exploitation provides arbitrary command execution under the invoking user's account. The resulting scope includes all files and secrets readable by that account and all operations it is authorized to perform. In an Ethereu ...[truncated 416 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the `curl | bash` pipeline. 2. Pin Foundry to a specific reviewed release rather than installing the latest mutable version. 3. Download the installer or release artifact as a separate file. 4. Verify it against a checksum or cryptographic signature published through an independent trusted channel. 5. Display or inspect shell installers before execution. 6. Execute installation with an unprivileged account and only the filesystem permissions it requires. 7. Document the expected download URL, version, checksum, signer identity, and verification commands. 8. Prefer a trusted package manager or official signed release artifacts where available. A safer workflow should follow this pattern: ```bash # Download a specifically pinned release artifact. # Verify its published checksum or signature. # Install it only after verification succeeds. ``` ]]>

T08 · Insecure Dependencies

Warning
Location
SKILL.md:57
Finding
Unpinned Packages Are Installed Globally from Mutable Registry Sources<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:57-59` **Vulnerability Type**: Unpinned global dependency installation **Risk Level**: Medium ### Vulnerable Code ```markdown - **Node.js 18+** and **pnpm** - `npm install -g pnpm` - **Foundry** (forge, anvil, cast) - `curl -L https://foundry.paradigm.xyz | bash && foundryup` - **Cannon CLI** - `pnpm add -g @usecannon/cli` ``` The dependency-specific vulnerable commands are: ```bash npm install -g pnpm pnpm add -g @usecannon/cli ``` ### Technical Analysis The commands install the latest available versions of `pnpm` and `@usecannon/cli` without exact version constraints, a lockfile, recorded integrity values, or provenance verification. The packages are installed globally, broadening their effect beyond the audited project. Package-manager installations may execute lifecycle scripts during installation. Consequently, compromise of the registry, a maintainer account, a package release, or one of its transitive dependencies could result in code execution during setup. Even without malicious compromise, mutable latest-version installation can introduce unreviewed behavior after this skill has been audited. Installing Cannon is related to the declared functionality, but global, unpinned installation exceeds the minimum-risk approach. A project-local, pinned dependency would provide the necessary command while limiting system-wide effects and improving reproducibility. ### Attack Path 1. An attacker compromises a package maintainer account, package release process, registry delivery path, or transitive dependency. 2. A malicious or otherwise unsafe release becomes the version selected by the unpinned install command. 3. A user or agent follows the setup instructions. 4. The package manager retrieves the mutable release and may execute its lifecycle scripts. 5. Malicious installation code runs with the permissions of the user performing the global installation. 6. The installed global executabl ...[truncated 602 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin exact reviewed versions, for example `package@x.y.z`, rather than selecting the latest release. 2. Prefer project-local development dependencies over global installation. 3. Commit and enforce a lockfile containing resolved versions and integrity metadata. 4. Verify package provenance and registry configuration before installation. 5. Review transitive dependencies and package lifecycle scripts. 6. Disable lifecycle scripts during installation where feasible, then explicitly run only reviewed setup steps. 7. Use a dedicated, minimally privileged development environment or container. 8. Document a controlled upgrade and re-audit process for changing pinned versions. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:196
Finding
Deployment Private Keys Are Passed Through Process Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Locations**: - `SKILL.md:196-204` - `references/cli.md:26` - `references/cli.md:48` - `references/cli.md:92` - `references/cli.md:192` - `references/cli.md:207` **Vulnerability Type**: Sensitive credential exposure through process arguments **Risk Level**: High ### Vulnerable Code The primary real-network examples expand a private key into a command-line argument: ```bash # Deploy to mainnet cannon build --chain-id 1 --rpc-url $RPC_URL --private-key $KEY # Publish to registry cannon publish --chain-id 1 --rpc-url $RPC_URL --private-key $KEY # For simulation before actual deploy cannon build --chain-id 1 --rpc-url $RPC_URL --dry-run ``` The CLI reference repeatedly documents the same option: ```markdown - `--private-key <key>` — Private key for deployment (or set `CANNON_PRIVATE_KEY` env var) - `--private-key <key>` — Private key for transactions (or set `CANNON_PRIVATE_KEY` env var) - `--private-key <key>` — Private key with publish permissions (or set `CANNON_PRIVATE_KEY` env var) - `--private-key <key>` — Owner's private key - `--private-key <key>` — Private key ``` ### Technical Analysis When `$KEY` is expanded by the shell, the private key becomes part of the Cannon process argument vector. Depending on the operating system and environment, command-line arguments may be observable through process inspection, diagnostic tooling, audit systems, monitoring agents, crash reports, shell wrappers, or CI/CD logging. The skill does mention alternatives such as `CANNON_PRIVATE_KEY` and stdin. However, the prominent mainnet deployment and publishing examples use the command-line form, encouraging unsafe secret handling for operations involving real funds and permanent package-management authority. The examined documentation does not prove that Cannon sends the raw private key over the network. A typical blockchain client signs transactions locally and sends signed transaction data to an RPC endpoint. The confirmed ...[truncated 1373 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove private-key command-line examples from all documentation. 2. Prefer hardware wallets, external signers, protected keystores, or managed signing services so raw keys are not supplied to the CLI. 3. Where supported, request sensitive input interactively through a no-echo prompt or protected stdin. 4. If an environment variable must be supported, scope it to a single process and clearly warn that environment variables may also be exposed through diagnostics or process inspection in some environments. 5. Never place secrets in shell history, scripts, configuration committed to source control, CI command text, or ordinary logs. 6. Use dedicated deployment accounts with minimal balances and narrowly scoped permissions. 7. Require multisignature authorization for high-value deployments, package ownership, and publisher-management operations. 8. Add explicit documentation explaining that RPC URLs may contain credentials and must also be handled as secrets. 9. Preserve the existing dry-run and explicit-confirmation requirements, but clarify that simulation does not mitigate credential exposure from unsafe argument handling. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (9)

External Script Fetching

High
Category
Supply Chain
Content
Before using this skill, ensure these tools are installed:

- **Node.js 18+** and **pnpm** - `npm install -g pnpm`
- **Foundry** (forge, anvil, cast) - `curl -L https://foundry.paradigm.xyz | bash && foundryup`
- **Cannon CLI** - `pnpm add -g @usecannon/cli`

Verify installation:
Confidence
94% confidence
Finding
The skill recommends piping a remote script directly into bash (`curl ... | bash`) to install Foundry. This is a real supply-chain risk because it executes network-fetched code without verification, exposing users to compromise if the host, transport, or upstream distribution path is tampered with. In this skill's context, the danger is heightened because the tool manages blockchain deployments and may coexist with private keys, RPC credentials, and other sensitive developer secrets.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
```

Options:
- `--no-confirm` — Skip confirmation prompt
- `--ipfs` — Delete only unreferenced IPFS packages

## Verify Command
Confidence
75% confidence
Finding
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The CLI documentation explicitly instructs users to pass a private key via a command-line flag or environment variable, but it does not include any warning about secret handling risks such as shell history exposure, process listing visibility, CI log leakage, or accidental sharing of environment configuration. In a deployment tool for Ethereum, these credentials directly control funds and package publishing authority, so omission of operational safety guidance materially increases the chance of credential compromise.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
- `--write-deployments <dir>` — Output directory for deployment files
- `--upgrade-from <ref>` — Upgrade from existing package (only if auto-detected package is wrong)

Note: If `cannon <package>` is run and the command isn't recognized, Cannon automatically executes `cannon run <package>`.

## Run Command
Confidence
80% confidence
Finding
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Missing User Warnings

Medium
Confidence
89% confidence
Finding
The publish command documents use of a private key and RPC endpoint but does not warn that publishing may expose transaction metadata, package contents, or related deployment information to external RPC, registry, and IPFS-adjacent services. For a package manager that publishes on-chain and to external infrastructure, users should be clearly informed that sensitive operational data may leave their environment.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
```

Options:
- `--no-confirm` — Skip confirmation prompt
- `--ipfs` — Delete only unreferenced IPFS packages

## Verify Command
Confidence
85% confidence
Finding
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
```

Options:
- `--no-confirm` — Skip confirmation prompt
- `--ipfs` — Delete only unreferenced IPFS packages

## Verify Command
Confidence
65% confidence
Finding
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The documentation explains that publishing makes a package available on the on-chain registry and IPFS, but it does not prominently warn users before the publish workflow that published artifacts are publicly accessible and effectively permanent. In this skill context, users may publish deployment metadata, ABIs, transaction data, and potentially source code, creating a real risk of unintended disclosure of sensitive project information.

Missing User Warnings

Low
Confidence
91% confidence
Finding
The clean command section documents cache deletion commands but does not clearly warn that these operations remove local cached artifacts and may disrupt offline reuse or force re-fetching of packages. While this is not a confidentiality or code-execution issue, it can still lead to accidental data loss or workflow disruption if users run the command without understanding its destructive effect.

Static analysis

No suspicious patterns detected.