ClawHub
Back to skill

Security audit

pocket-money

Security checks for vulnerabilities and agentic risk

Overview

This skill is transparent about giving an agent a small USDC wallet, but users should treat it as real money handling with local private-key risk.

Install only if you are comfortable letting the agent manage small, purpose-specific USDC balances. Keep wallet files out of source control and backups, fund only limited amounts, review or pin the npm package where possible, and require explicit approval before every spend.

A.I.G

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:12
Finding

Unpinned Third-Party Package Installation

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 12-15 and 27-31
Vulnerability Type: Supply-chain exposure through an unpinned npm dependency
Risk Level: Medium

Vulnerable Code

yaml
install:
  - kind: node
    package: "@auteng/pocket-money"
    bins: []
markdown
Install the pocket-money library:

```bash
npm install @auteng/pocket-money
text

### Technical Analysis

The Skill installs `@auteng/pocket-money` without specifying an exact version or an integrity-verified lockfile. Consequently, installation resolves whichever package release the npm registry currently associates with the applicable default tag, normally `latest`.

The installed dependency handles cryptocurrency wallet creation and private keys. A compromised publisher account, malicious future release, registry compromise, or dependency takeover could therefore introduce code that differs from the version originally reviewed. The artifact contains no implementation or lockfile with which to independently verify the installed package's behavior.

### Attack Path

1. An attacker compromises the npm publisher, package release process, or registry entry for `@auteng/pocket-money`.
2. The attacker publishes a malicious release under the package's default distribution tag.
3. The Agent follows the Skill instructions and runs `npm install @auteng/pocket-money`, or the Skill framework performs the equivalent unpinned installation.
4. npm downloads and executes the changed package with the Agent process's local filesystem and network permissions.
5. Malicious package code accesses wallet files, substitutes payment destinations, captures newly generated private keys, or transmits sensitive material externally.
6. The attacker uses any captured keys to authorize unauthorized blockchain transactions.

### Impact Assessment

Successful exploitation could provide access to the files and network resources available to the Agent's operating-system account. In the context of
...[truncated 442 chars]
Remediation
View remediation

Remediation Suggestions

  1. Pin @auteng/pocket-money to an exact, reviewed version in both installation declarations and examples; do not use version ranges or mutable distribution tags.
  2. Commit a package lockfile containing registry integrity hashes and install with npm ci.
  3. Review the package source and its transitive dependencies before approving upgrades.
  4. Use automated dependency monitoring, provenance verification, and signature or attestation checks where available.
  5. Prefer vendoring the reviewed implementation or including auditable source in the Skill artifact when it handles private keys.
  6. Run the dependency with least privilege, restricted filesystem access, and network egress controls.
  7. Require explicit review whenever the pinned version or lockfile changes.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:144
Finding

Cryptocurrency Private Keys Stored Unencrypted on Disk

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, line 144
Vulnerability Type: Plaintext storage of sensitive cryptographic material
Risk Level: Medium

Vulnerable Code

markdown
**Private keys**: Wallet private keys are stored as unencrypted JSON at `.auteng/wallets/<name>.json` with restricted file permissions (0600). These keys can sign USDC payment authorizations. If the file is leaked or the machine is compromised, funds in that wallet can be stolen. Treat wallet files like passwords.

Technical Analysis

Wallet private keys are deliberately persisted as unencrypted JSON. File mode 0600 prevents access by other ordinary local users, but it does not cryptographically protect the keys. Any process operating as the wallet owner can read them. The keys may also be exposed through malware, accidental repository inclusion, insecure backups, filesystem snapshots, support bundles, or compromise of the host or user account.

Possession of a blockchain private key is sufficient to produce valid signatures. Human-approval instructions in the Skill cannot prevent an attacker who obtains the key from signing transactions independently.

Attack Path

  1. A malicious or compromised process gains read access under the same operating-system account as the Agent, or an attacker obtains a backup, snapshot, archive, or accidentally committed wallet file.
  2. The attacker reads .auteng/wallets/<name>.json.
  3. The attacker extracts the plaintext private key.
  4. The attacker imports the key into a separate wallet or signing tool.
  5. The attacker signs payment authorizations or other transactions without interacting with the Skill's human-approval workflow.
  6. Assets controlled by the affected wallet are transferred to an attacker-controlled address.

Impact Assessment

Disclosure grants control equivalent to the affected wallet owner and can result in irreversible theft of all assets authorized by that key. The compromise applies ...[truncated 343 chars]

Remediation
View remediation

Remediation Suggestions

  1. Store private keys in an operating-system keychain, hardware-backed keystore, hardware wallet, or dedicated secrets-management service.
  2. If file persistence is unavoidable, encrypt each key with authenticated encryption and derive the encryption key from a user-supplied secret using a memory-hard key derivation function.
  3. Keep decryption secrets separate from wallet files and do not persist them in the same project or configuration directory.
  4. Preserve restrictive permissions, but treat them as defense in depth rather than encryption.
  5. Add .auteng/wallets/ to source-control exclusion rules and exclude it from routine logs, support bundles, and unencrypted backups.
  6. Restrict Agent and dependency access to the wallet directory using sandboxing and least-privilege filesystem controls.
  7. Maintain only small operational balances, use separate wallets per purpose, support rapid key rotation, and transfer remaining funds immediately after suspected exposure.
  8. Ensure sensitive key material is never printed in logs, error messages, telemetry, or diagnostic output.

SkillSpector

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.