T08 · Insecure Dependencies
Error
- Location
SKILL.md:15- Finding
Unpinned Third-Party CLI Execution in Wallet Operations
- Content
View full analysis
``` ``` The same unpinned `npx @cavos/cli` invocation pattern is also used for balance queries, transfers, token approvals, arbitrary contract execution, multicalls, simulation, and transaction-status operations throughout lines 31–66. ### Technical Analysis The Skill executes `@cavos/cli` by package name without specifying an audited version, integrity hash, lockfile, or verified local installation. Depending on the environment and local package availability, `npx` can retrieve and immediately execute a package release from the configured npm registry. Consequently, the code executed by this reviewed Skill is not immutable. A future package update, compromised publisher account, registry compromise, or malicious dependency introduced into the package could change the effective behavior without any corresponding change to `SKILL.md`. This is particularly security-sensitive because the CLI is instructed to handle session tokens and perform asset transfers, approvals, and arbitrary Starknet contract calls. Malicious package code would execute with the operating-system privileges, environment access, filesystem access, and network access granted to the agent process. ### Attack Path 1. An attacker compromises the `@cavos/cli` publisher account, its release process, or a transitive dependency. 2. The attacker publishes a malicious release under the expected package name. 3. An ag ...[truncated 1596 chars]- Remediation
View remediation
whoami --json ``` 2. Prefer installing the audited version ahead of time through a committed lockfile containing registry resolution and integrity metadata. Do not permit arbitrary runtime dependency resolution. 3. Invoke the verified local binary with network installation disabled: ```bash npx --no-install cavos whoami --json ``` Alternatively, execute the package binary directly from a controlled installation. 4. Verify the package source, maintainer identity, release provenance, integrity data, and transitive dependency tree before approving a version. Require a new review before upgrading. 5. Run the CLI in a sandbox with minimal filesystem, environment, and network access. Expose only the credentials and wallet permissions required for the current operation. 6. Apply restrictive wallet session policies, including transaction-value limits, approved contract and token allowlists, short expiration periods, and narrowly scoped methods. 7. Require explicit confirmation of transaction-critical fields—including network, recipient, token, amount, spender, contract, entrypoint, and calldata—before signing or submission. 8. Avoid passing session tokens directly on the command line where they may be retained in shell history or exposed through process inspection. Use a documented secure input mechanism if the CLI supports one. ]]>