Back to skill

Security audit

one-wallet

Security checks for vulnerabilities and agentic risk

Overview

This wallet skill is mostly coherent, but it gives agents broad authority around irreversible blockchain transactions and private keys without enough guardrails.

Review before installing. Use this only in a dedicated, least-privileged environment with test wallets or limited funds. Do not paste real private keys into commands or chat transcripts, avoid -y unless a recipient and amount are pre-approved, pin the CLI version or commit where possible, and require explicit confirmation before any transaction, approval, contract write, wallet deletion, or signature.

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:38
Finding
Unpinned Third-Party Package Installation and Build<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:38-61` **Vulnerability Type**: Unpinned and mutable third-party dependencies **Risk Level**: Medium ### Vulnerable Code ```bash npm install -g one-wallet # or yarn global add one-wallet # or pnpm add -g one-wallet ``` ```bash git clone https://github.com/viyozc/one-wallet.git cd one-wallet yarn install yarn build ./bin/run.js --help ``` ### Technical Analysis The documented installation workflows retrieve and execute mutable third-party content without pinning an audited package version, Git commit, or dependency set. The global package installation commands resolve the package version available from the registry at installation time. The repository workflow clones the current default branch and then runs dependency installation and build operations. Package-manager lifecycle scripts and build scripts can execute code with the privileges of the user running the commands. No malicious package or repository content was found in the audited project itself. The risk arises because the skill directs an agent or user to trust external content whose effective implementation can change after this skill has been reviewed. ### Attack Path 1. An attacker compromises the package registry entry, upstream repository, maintainer account, release process, or a transitive dependency. 2. The attacker publishes a modified package, changes the repository's default branch, or introduces a malicious dependency or lifecycle script. 3. A user or agent follows the skill instructions and runs the unpinned installation or build command. 4. The package manager retrieves the attacker-controlled version and executes installation, lifecycle, or build scripts. 5. The malicious code executes with the installing user's privileges and may access files, environment variables, wallet configuration, or credentials available to that account. ### Impact Assessment Successful exploitation could provide arbitrary code execution u ...[truncated 358 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Pin `one-wallet` to a reviewed, immutable version rather than installing the latest available release. - For source installations, check out a specific reviewed commit hash or signed release tag before installing dependencies or building. - Verify package integrity, provenance, and release signatures where supported. - Use a committed lockfile and an immutable or frozen-lockfile installation mode. - Review package lifecycle and build scripts before execution. - Prefer a local, isolated installation over a global installation. - Run installation and wallet tooling in a dedicated, least-privileged environment that does not expose unrelated credentials or wallet secrets. - Periodically reassess the pinned version and its transitive dependencies before upgrading. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:106
Finding
Private Keys Exposed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:106-115` **Vulnerability Type**: Sensitive information exposure through process arguments and shell history **Risk Level**: High ### Vulnerable Code ```bash # Import from private key: one-wallet wallet import <name> --private-key 0xYourPrivateKey # Import with password: one-wallet wallet import <name> --private-key 0xYourPrivateKey --password --set-default ``` ### Technical Analysis The documented import workflow places an EVM private key directly in a command-line argument. Depending on the operating system, shell, and execution environment, command arguments can be exposed through: - Shell history files - Process listings and process-inspection interfaces - Terminal session recording - CI/CD command logs - Agent execution transcripts - Debugging, audit, or telemetry systems Password-protecting the resulting wallet does not protect the private key while it is present in the command invocation. Because an EVM private key directly authorizes signatures, disclosure is sufficient to impersonate the wallet owner without compromising the wallet application's stored encrypted data. ### Attack Path 1. A user substitutes a real private key into the documented `--private-key` argument. 2. The shell, operating system, automation platform, or logging system records or exposes the command. 3. A local user, administrator, log reader, CI operator, or attacker with access to the relevant history or telemetry obtains the private key. 4. The attacker imports the key into another wallet or signing tool. 5. The attacker signs unauthorized transactions or messages without requiring access to the original `one-wallet` installation. ### Impact Assessment An exposed private key grants control over the corresponding EVM account. An attacker can transfer native currency and tokens, move NFTs, approve token spenders, interact with contracts, and produce valid signatures as that account. Transactions are generally ...[truncated 112 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Remove examples that place private keys directly in command-line arguments. - Prefer an interactive hidden prompt that reads the key without echoing it. - Support input through a protected file descriptor, standard input with appropriate safeguards, or an operating-system secret manager. - If file-based import is unavoidable, require restrictive file permissions, avoid shared temporary directories, and securely delete the temporary material when feasible. - Explicitly warn users that private keys must not be entered into shell arguments, scripts, CI logs, or agent transcripts. - Configure automation systems to mask secrets and disable command tracing around sensitive operations. - Document incident response for accidental exposure: treat the key as compromised, create a new wallet, transfer assets and authorities, revoke approvals where possible, and discontinue use of the exposed key. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (4)

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The overview advertises wallet creation, sending transactions, contract interaction, and signing without an immediate warning that these actions can move funds irreversibly or authorize on-chain effects. In an agent setting, presenting destructive financial capabilities up front without strong cautionary framing increases the risk of accidental loss, misuse, or unsafe execution based on ambiguous user requests.

Vague Triggers

Medium
Confidence
86% confidence
Finding
The skill says to use one-wallet for Ethereum/EVM tasks that can be done via CLI, even when the user did not specifically request this tool. That broad routing can cause the agent to select a wallet-capable skill for generic blockchain tasks, increasing the chance of exposing wallet operations, signing flows, or transaction commands in contexts where a read-only or safer tool would be more appropriate.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
one-wallet wallet send 0xRecipientAddress 0.1
```

Skip confirmation for scripts:

```bash
one-wallet wallet send 0xRecipientAddress 0.1 -y
Confidence
91% confidence
Finding
The skill explicitly documents use of `-y` to skip confirmation for transaction sending, which facilitates unattended execution of value-transfer actions. In an autonomous or semi-autonomous agent environment, bypassing confirmations removes an important safety barrier against mistaken recipients, wrong amounts, or malicious prompt steering that leads to irreversible on-chain transactions.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
- Never hard-code real private keys or passwords in source-controlled files.
- Prefer `ONE_WALLET_KEY_<NAME>` and `ONE_WALLET_PASSWORD_<NAME>` environment variables for secrets.
- Use `--json` for automation; omit it for quick human inspection.
- Use `-y` only in scripts or when the user explicitly wants to skip confirmations.
- When in doubt about the chain or RPC, call `one-wallet provider info` before sending transactions.

## Reference
Confidence
85% confidence
Finding
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Static analysis

No suspicious patterns detected.