T08 · Insecure Dependencies
Error
- Location
- SKILL.md:66
- Finding
- Unpinned Third-Party Package Execution with Access to Financial Credentials## Vulnerability Details **File Location**: `SKILL.md:66-71` **Additional Location**: `SKILL.md:104` **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: High **Vulnerable Code Snippet**: ```bash export WALLET_KEY=... # DEDICATED wallet: EVM 0x key, or base58 Solana key export LLM_API_KEY=... # any OpenAI-compatible API for the drafting step export LLM_MODEL=... npx x402-bounty-hunter --dry-run # read and price the work, pay nothing npx x402-bounty-hunter # one real attempt at the best-odds bounty ``` A second unpinned package invocation is documented at `SKILL.md:104`: ```text Reference CLI: `npx @deskcrew/board-runner`. ``` ### Technical Analysis The skill instructs users to execute npm packages directly through `npx` without specifying an exact version, package integrity digest, lockfile, or immutable source revision. When a package is unavailable locally, `npx` can download and execute the version currently supplied by the npm registry. Consequently, the effective executable payload can change after this skill has been reviewed. This is particularly sensitive because the process runs after `WALLET_KEY` and `LLM_API_KEY` have been exported into its environment. The bounty client is also expected to sign real USDC payment authorizations and communicate with external services. A malicious package release, compromised publisher account, registry substitution, or compromised transitive dependency could therefore access secrets and execute arbitrary code under the invoking user's account. The documentation links to a GitHub repository and describes client-side safeguards, but the audited project contains no client source, dependency manifest, lockfile, integrity metadata, or reproducible-build evidence demonstrating that the npm artifact matches the referenced source. The claimed token pinning and spending limits therefore cannot be independently verified from the supplied file ...[truncated 2196 chars]
- Remediation
- ## Remediation Suggestions 1. Pin every executable npm package to a reviewed exact version, such as `x402-bounty-hunter@X.Y.Z`, rather than relying on the registry's current release. 2. Verify the downloaded package with a trusted integrity digest and npm provenance metadata. Bind the artifact to a reviewed source commit and document the verification procedure. 3. Include auditable client source, a dependency manifest, and a lockfile in the skill package, or vendor the reviewed implementation rather than downloading executable code at runtime. 4. Use reproducible builds and publish signed release artifacts so users can confirm that the npm package corresponds to the referenced repository and commit. 5. Execute the client in a restricted container or sandbox with minimal filesystem access, outbound network access limited to necessary endpoints, and no unrelated environment variables or host credentials. 6. Continue requiring a dedicated, low-balance wallet. Do not place unrelated assets in it, and rotate the wallet immediately if package integrity is uncertain. 7. Use a separate, narrowly scoped LLM API credential with strict quota and billing limits. 8. Independently enforce transaction limits outside the downloaded client where possible, such as through restricted smart-wallet policies or wallet-level controls. 9. Apply the same pinning, integrity verification, and sandboxing controls to `@deskcrew/board-runner`. 10. Reconcile `WALLET_KEY` and `X402_KEY` throughout `SKILL.md` and `SECURITY.md` so the security model accurately identifies the secret consumed by the executable.