Back to skill

Security audit

create-crypto-wallets

Security checks for vulnerabilities and agentic risk

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.

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 (3)

T08 · Insecure Dependencies

Warning
Location
skill.md:23
Finding

Unpinned Third-Party Python Dependencies

Content
View full analysis

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
View 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

Content
View full analysis

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
View 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

Content
View full analysis

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
View 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.
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • 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
Findings (1)

Sudo/Root Execution

Medium
Category
Privilege Escalation
Confidence
80% confidence
Finding

Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Content

Scanner excerpt · skill.md (reported line 172)May include surrounding context.

md
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.