create-crypto-wallets

• Outcome: Review
• Latest audit: Sep 16, 2026 · 10:36 AM UTC
• Version: 1.0.1

Overview

This is coherent crypto-wallet guidance, but it should be reviewed because its examples can expose wallet recovery secrets in logs and use mutable third-party installs.

Install only after deciding how wallet secrets will be protected. Use test or minimally funded wallets, avoid shared terminals and CI, do not let mnemonics or private keys enter agent transcripts or logs, pin and review dependencies, and inspect any external secret-management skill before using it with real wallet material.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T08 · Insecure Dependencies

Warning

• Location: skill.md:23
• Finding: Unpinned Third-Party Python Dependencies## Vulnerability Details **File Location**: `skill.md:23` **Vulnerability Type**: Supply-chain exposure through unpinned dependencies **Risk Level**: Medium **Code Snippet**: ```bash pip install python-dotenv hdwallet[cli] ``` ### Technical Analysis The setup command installs `python-dotenv`, `hdwallet`, and the dependencies associated with the `cli` extra without version constraints or cryptographic hash verification. Consequently, installation results can change over time without any modification to the audited Skill. Python packages and their transitive dependencies may execute code during installation or when imported. If a package publisher account, release process, dependency, or package repository is compromised, a malicious release could execute with the privileges of the user following these instructions. A virtual environment isolates Python package placement but does not prevent package code from accessing files, environment variables, terminal data, or wallet secrets available to that user. ### Attack Path 1. An attacker compromises a dependency publisher, one of its transitive dependencies, or the relevant package distribution channel. 2. The attacker publishes a malicious version that still satisfies the unconstrained installation command. 3. A user follows the documented setup instructions and installs the current package versions. 4. Malicious installation or runtime code executes under the user's account. 5. The code accesses wallet material, environment variables, local files, or other resources available to that account and may transmit or modify them. ### Impact Assessment Successful exploitation could provide code execution with the privileges of the user running `pip`. The affected scope includes files and credentials accessible to that user, including generated mnemonic phrases, private keys, environment variables, and wallet output. This instruction does not itself request elevated privileges, s ...[truncated 114 chars]
• Remediation: ## Remediation Suggestions - Pin every direct dependency to a reviewed version, for example through a locked requirements file. - Resolve and pin transitive dependencies rather than constraining only top-level packages. - Generate and verify package hashes, using mechanisms such as `pip install --require-hashes -r requirements.txt`. - Obtain packages only from the expected trusted index and explicitly configure the index where appropriate. - Review dependency release provenance, vulnerability advisories, and package ownership before updating. - Test upgrades in an isolated environment before permitting them in workflows that handle wallet credentials. - Consider separating dependency installation from wallet generation so installation-time code never runs in a process or environment containing wallet secrets.

T09 · Insecure Skill Coding Practices

Error

• Location: skill.md:146
• Finding: Wallet Recovery Secrets Printed to Standard Output## Vulnerability Details **File Location**: `skill.md:146-150` **Vulnerability Type**: Plaintext exposure of mnemonic and private-key material **Risk Level**: High **Code Snippet**: ```python print(wallet.mnemonic()) # the mnemonic phrase — BACK THIS UP, it recovers the whole wallet print(wallet.private_key()) # derived private key (hex) print(wallet.public_key()) # derived public key (hex) print(wallet.address()) # derived address for the configured account/change/address index print(wallet.xprivate_key()) # extended private key (xprv...) ``` ### Technical Analysis The example prints a wallet mnemonic, a derived private key, and an extended private key directly to standard output. These values are authentication and recovery credentials, not ordinary diagnostic information: - The mnemonic can recreate the entire deterministic wallet. - A private key permits control over assets associated with the corresponding address. - An extended private key can permit derivation of a branch of private keys and addresses, depending on its derivation level. Standard output is frequently retained in terminal scrollback, shell-session recordings, CI logs, Agent transcripts, remote console captures, or redirected files. The public key and address are not secret, but placing secret and public values in the same demonstration encourages users to treat all output as routine diagnostic data. The later warning against logging secrets does not prevent the example itself from disclosing them. ### Attack Path 1. A user copies and executes the documented Python example using a real or funded wallet. 2. The mnemonic, private key, and extended private key are emitted as plaintext. 3. The output is retained in terminal scrollback, a CI log, an Agent conversation, a remote session recording, or a redirected output file. 4. Another user, process, log operator, or compromised service gains access to the retained outp ...[truncated 844 chars]
• Remediation: ## Remediation Suggestions - Remove `print()` calls for mnemonic phrases, private keys, extended private keys, entropy, and seeds from the default example. - Demonstrate only non-secret output such as the public address and, where necessary, the public key. - If secret export is required, make it a separate, explicitly named operation with a prominent warning and user confirmation. - Write exported credentials only to an encrypted secret store or hardware-backed wallet facility. - If a temporary file is unavoidable, create it atomically with owner-only permissions, avoid predictable paths, and securely remove it immediately after use. - Prevent secret-bearing output from entering CI logs, Agent transcripts, telemetry, exception messages, or shell history. - Use a deliberately marked test mnemonic with no funds when documentation must illustrate secret-access APIs. - Clarify the differing compromise scopes of a mnemonic, an individual private key, and an extended private key.

T08 · Insecure Dependencies

Warning

• Location: skill.md:184
• Finding: Direct Installation of an Unpinned External Skill## Vulnerability Details **File Location**: `skill.md:184` **Vulnerability Type**: Unverified external Skill dependency **Risk Level**: Medium **Code Snippet**: ```bash openclaw skills install @beocca/keepass-cli ``` ### Technical Analysis The documentation recommends directly installing an externally maintained Skill by a mutable name without identifying a reviewed version, commit, package digest, or integrity value. The installed content may therefore differ from the content available when this project was audited. This dependency is particularly sensitive because it is recommended for storing mnemonic phrases and private keys. If the external Skill is compromised, replaced, or later updated with unsafe behavior, it may be used in a workflow with direct access to high-value wallet credentials. The audited project does not itself contain the external Skill's implementation, and no malicious behavior by that Skill was established. The issue is the trust and installation model: users are instructed to retrieve mutable third-party content without an explicit review or integrity-verification step. ### Attack Path 1. An attacker compromises the external Skill's publisher account, distribution record, source repository, or release process. 2. The attacker publishes modified content under the same mutable Skill identifier. 3. A user follows the direct installation command from this documentation. 4. The unreviewed modified Skill is installed into the user's environment. 5. The user later invokes it to store or retrieve wallet mnemonic phrases or private keys. 6. Malicious instructions or code in the external Skill captures, modifies, or discloses those credentials. ### Impact Assessment The immediate impact is installation of unaudited, changeable third-party content. If that content executes code or influences Agent actions during secret-management workflows, the effective scope can include wallet credentials, the user ...[truncated 385 chars]
• Remediation: ## Remediation Suggestions - Pin the external Skill to an immutable, reviewed version, commit, or digest if the platform supports that capability. - Document the expected publisher, source repository, version, and integrity value. - Require users to inspect the downloaded Skill's instructions, scripts, permissions, and network behavior before installation or invocation. - Re-audit the dependency whenever its pinned version changes. - Avoid automatic updates for components that process mnemonic phrases or private keys. - Treat the external Skill as optional and clearly separate its installation from the core wallet-generation procedure. - Prefer a locally reviewed secret-management mechanism with encrypted storage, least-privilege access, and no unnecessary network connectivity.

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

Never print these to shared logs, commit them to version control, or send them over an insecure channel.
- Prefer deriving from a mnemonic you generate once and store securely, rather than regenerating
  entropy per-session — regenerating creates a brand-new, unrelated wallet each time.
- If writing wallet material to disk, restrict file permissions (e.g. `chmod 600`) and keep the
  file out of any directory tracked by git (add it to `.gitignore`).
- Use a dedicated wallet with a minimal balance for agentic/automated use to limit exposure if the
  key is ever leaked.

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Static analysis

No suspicious patterns detected.