solclaw

• Outcome: Review
• Latest audit: Sep 10, 2026 · 10:58 AM UTC
• Version: 1.0.0

Overview

This payment skill is coherent, but it gives users wallet-sensitive commands with weak safety boundaries around private keys, package provenance, and persistent monitoring.

Review this skill carefully before installing. Use only devnet-only wallets, do not paste real private keys into shell commands, avoid `--quiet` key export unless you fully control the output channel, pin and verify the CLI package before running it, and treat the heartbeat cron job and its logs as sensitive operational data.

A.I.G

Vulnerability Patterns

• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• 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

Findings (3)

T06 · System Persistence

Warning

• Location: heartbeat.md:111
• Finding: Persistent Five-Minute Cron Job Introduces Unnecessary Cross-Session Execution<![CDATA[ ## Vulnerability Details **File Location**: `heartbeat.md:111-115` **Vulnerability Type**: Persistent scheduled-task registration **Risk Level**: Medium ### Vulnerable Code ```bash # Edit crontab crontab -e # Add line to run every 5 minutes */5 * * * * /path/to/heartbeat.sh >> /var/log/solclaw-heartbeat.log 2>&1 ``` ### Technical Analysis The instructions encourage users to install a cron entry that executes `heartbeat.sh` every five minutes and persists across terminal sessions, reboots, and individual skill invocations. Periodic monitoring is related to the heartbeat functionality, but permanent operating-system scheduling is not necessary for the core on-demand payment functionality. The cron entry trusts a mutable filesystem path without documenting ownership, integrity controls, restrictive permissions, or safe removal. If another account or process can modify the script or one of its parent directories, the scheduled job becomes a recurring command-execution mechanism under the account that installed it. The suggested `/var/log/solclaw-heartbeat.log` destination may require elevated permissions on typical systems. This could lead users to run setup steps with unnecessary privileges or weaken log-file permissions. ### Attack Path 1. A user creates `heartbeat.sh` and installs the provided cron entry. 2. The scheduled task remains active across future sessions and system restarts. 3. An attacker compromises or replaces the referenced script, or gains write access to one of its parent directories. 4. Cron executes the modified script automatically every five minutes. 5. The attacker's commands run with the permissions of the user who owns the crontab. 6. If the task was installed under a privileged account, the resulting commands inherit that account's broader access. ### Impact Assessment Successful exploitation provides recurring command execution under the cron owner's account. This can expose files, wallet configuration, environment ...[truncated 439 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Make scheduled monitoring explicitly optional and require informed user confirmation before installation. - Prefer on-demand checks for the default workflow. - If scheduling is required, use a dedicated, unprivileged user-level timer with sandboxing and resource limits. - Store the script in a user-owned directory with restrictive permissions, such as mode `0700` for the directory and `0700` or `0500` for the script. - Verify that neither the script nor its parent directories are writable by untrusted users. - Write logs to a user-owned location rather than `/var/log`, and configure log rotation and restrictive permissions. - Use absolute paths for the executable and all referenced files. - Document how to inspect and remove the cron entry. - Avoid installing the task under `root` or requesting elevated privileges. ]]>

T08 · Insecure Dependencies

Error

• Location: skill.md:28
• Finding: Unpinned npx Package Executes Wallet-Sensitive Third-Party Code<![CDATA[ ## Vulnerability Details **File Location**: `skill.md:28-40` **Vulnerability Type**: Unpinned third-party package execution **Risk Level**: High ### Vulnerable Code ```bash # 1. Initialize your agent npx solclaw-cli init --name "MyAgent" # 2. Get SOL for gas npx solclaw-cli faucet # 3. Register on-chain (creates your vault) npx solclaw-cli register # 4. Get USDC from Circle faucet -> paste your vault address # https://faucet.circle.com (Solana Devnet) # 5. Send USDC! npx solclaw-cli send --to "SolClaw" --amount 1 --memo "Hello!" ``` ### Technical Analysis The commands invoke `solclaw-cli` through `npx` without specifying an audited version, package integrity value, trusted repository commit, or signature. Depending on the local npm configuration and cache state, `npx` can retrieve and execute package content from a remote registry at invocation time. This is particularly sensitive because the package is expected to generate or access wallet keys, create vaults, sign transactions, and choose payment recipients. A compromised package release, registry account, dependency, or resolution configuration could therefore execute arbitrary code with the user's permissions and interact directly with financial credentials. The audited project contains only Markdown instructions, so the implementation and behavior of the downloaded package cannot be verified from the supplied artifact. ### Attack Path 1. An attacker compromises the `solclaw-cli` publishing account, one of its dependencies, the package registry, or the user's package-resolution configuration. 2. The attacker publishes or causes resolution to a malicious package version. 3. A user follows the documentation and runs an unversioned `npx solclaw-cli` command. 4. `npx` downloads and executes the attacker-controlled package. 5. The malicious package reads wallet files or other user-accessible secrets, changes payment parameters, or signs unintended transactions. 6. Stolen information may ...[truncated 697 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin the CLI to a specific reviewed version instead of resolving the latest release implicitly. - Provide package integrity hashes and verify them before execution. - Publish the authoritative package name, registry, source repository, release commit, and signing identity. - Use lockfiles and exact dependency versions for any locally installed tooling. - Audit the fixed CLI release and its transitive dependencies before recommending it for wallet operations. - Prefer reproducible, signed release artifacts and verify signatures against a documented trusted key. - Run initial verification in a restricted environment without valuable wallet material. - Require users to verify transaction recipient, amount, program ID, network, and mint before signing. - Avoid importing production wallets until the package provenance and implementation have been independently verified. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: skill.md:50
• Finding: Private Key Passed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `skill.md:50` and `skill.md:192` **Vulnerability Type**: Sensitive credential exposure through process arguments and shell history **Risk Level**: High ### Vulnerable Code At `skill.md:50`: ```bash # Import from base58 private key solclaw init --name "MyAgent" --private-key "your_base58_private_key..." ``` The same unsafe interface is reiterated at `skill.md:192`: ```markdown - **Base58 private key**: `--private-key "your_key..."` ``` ### Technical Analysis The documentation instructs users to place a wallet private key directly in a command-line argument. Command-line secrets can be exposed through shell history, process inspection interfaces, terminal recording, audit logs, automation telemetry, crash reports, support transcripts, and copied command output. Quoting the private key does not provide confidentiality; it only affects shell parsing. While visibility of process arguments varies by operating system and configuration, shell-history persistence alone creates a durable credential-exposure risk. A Solana private key is sufficient to authorize transactions for its corresponding wallet. Unlike a password protected by a server-side revocation mechanism, a leaked private key generally remains usable until assets and authorities are migrated to a new key. ### Attack Path 1. A user follows the documentation and enters the Base58 private key in the shell command. 2. The shell records the complete command in its history file, or the argument is captured through process monitoring, terminal logging, or automation telemetry. 3. Another local user, malicious process, compromised monitoring tool, backup reader, or support recipient obtains the recorded command. 4. The attacker extracts the private key. 5. The attacker imports the key into another Solana-compatible wallet or signing tool. 6. The attacker signs unauthorized transactions and transfers assets or exercises any authorities controlled by th ...[truncated 502 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove command-line private-key examples from the documentation. - Accept private keys through protected standard input without terminal echo, an operating-system credential store, or a hardware wallet. - Prefer importing a permission-restricted keypair file by path rather than embedding its contents in the command. - Ensure key files are owned by the intended user and use mode `0600` or stricter. - Do not place secret values in environment variables when they may be exposed through diagnostics or process inspection. - Warn users never to paste keys into shell commands, logs, chat systems, or support tickets. - Recommend dedicated devnet-only keys and prohibit reuse of production wallet keys. - If a key has already been supplied on a command line, advise the user to clear relevant history and logs and, more importantly, rotate the wallet key and migrate all assets and authorities. - Add hardware-wallet or external-signer support before recommending use with valuable wallets. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Rogue Agent: Self-Modification, Session Persistence
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (11)

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: The documentation instructs users how to import and export private keys, including passing a base58 private key directly on the command line and exporting in quiet mode, without strong warnings about shell history, process inspection, screen logging, and plaintext key exposure. In a wallet/payment skill, this can directly lead to complete compromise of funds if secrets are exposed to other local users, logs, or monitoring tools.

Anti-Refusal Statement

High

• Category: Anti-Refusal

Content

solclaw export --quiet            # key only, no warnings

• Confidence: 84% confidence
• Finding: The phrase `export --quiet # key only, no warnings` suppresses safety messaging precisely for a command that outputs secret key material. Encouraging warning-free secret export increases the likelihood that users will handle private keys casually, automate insecure extraction, or leak them into logs and transcripts.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The heartbeat script and Node.js example print account balance, pending invoices, reputation, and spending-cap information to stdout, and the cron example redirects that output into a persistent log file. For a financial/payment skill, these records can expose sensitive operational and financial metadata to other local users, log collectors, backups, or support tooling without any warning or access-control guidance.

Session Persistence

Medium

• Category: Rogue Agent

Content

```bash
# Edit crontab
crontab -e

# Add line to run every 5 minutes
*/5 * * * * /path/to/heartbeat.sh >> /var/log/solclaw-heartbeat.log 2>&1

• Confidence: 85% confidence
• Finding: The cron setup establishes persistent, unattended execution of the heartbeat script every 5 minutes, which creates session/task persistence on the host. In this skill's context, persistence is part of the intended monitoring workflow, but it still increases exposure by continuously executing commands and continuously appending potentially sensitive payment data to logs.

Session Persistence

Medium

• Category: Rogue Agent

Content

Non-custodial USDC payments on Solana by agent name. Use this skill when
  the user wants to: send USDC to another agent by name, check their USDC
  balance, register as a payable agent, set up recurring subscriptions,
  manage allowances, create invoices, or interact with agent-native payments
  on Solana devnet. Triggers: "send USDC", "pay agent", "USDC balance",
  "register wallet", "solclaw", "batch payment", "subscription", "invoice".
---

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The quick-start flow leads users from wallet setup directly into funding and sending USDC without any explicit warning that transfers are irreversible or any recommendation for confirmation of recipient, network, and amount. In a financial skill, omission of confirmation guidance materially increases the chance of accidental loss through operator error or spoofed names.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 93% confidence
• Finding: Using `npx solclaw-cli` without pinning a specific package version allows whatever package is current in the registry at execution time to run on the user's machine. In a payments skill that initializes wallets and handles private keys, a compromised or malicious package update could exfiltrate credentials or alter transaction behavior with severe consequences.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 93% confidence
• Finding: This command invokes an unpinned npm package to request funds and interact with a blockchain wallet environment. Because `npx` resolves the latest matching package by default, a supply-chain compromise could lead to arbitrary code execution or wallet-targeting malware on the host.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 93% confidence
• Finding: Running `npx solclaw-cli register` without version pinning exposes users to remote package substitution at the moment they create on-chain payment state. In this context, an attacker-controlled package could generate attacker-known keys, modify registration targets, or misdirect future funds.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 95% confidence
• Finding: An unpinned `npx` command is especially dangerous when used for sending USDC, because the package executed can directly influence recipient resolution, transaction construction, and signing prompts. A malicious update could silently reroute payments, steal private keys, or trick users into approving unintended transfers.

Intent-Code Divergence

Low

• Confidence: 78% confidence
• Finding: Lines L151-L165 describe the API as 'read-only' and 'stateless', but `/api/due` is specifically framed as supporting execution of due subscriptions in the broader payment system. While the endpoint may still be implemented as a GET query, the documentation's characterization understates its operational role in triggering or coordinating recurring-payment activity.

Static analysis

No suspicious patterns detected.