T03 · Remote Payload Retrieval and Execution
- Location
workspace-template/openclaw.json:4- Finding
Automatic Execution of an Unpinned Remote npm Package
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a disclosed crypto trading integration, but it gives an agent broad real-money wallet and trading authority with weak technical scoping and a mutable runtime package.
Review this skill carefully before installing. Use only low-balance, revocable, tightly scoped OpenPump credentials if available; avoid @latest startup execution; avoid storing the key in plaintext; and require explicit, transaction-specific approval for buys, sells, transfers, token launches, sniping, market making, and spam launches. The README also says it is not available to US persons, so verify eligibility before use.
workspace-template/openclaw.json:4Automatic Execution of an Unpinned Remote npm Package
workspace-template/openclaw.json:2Excessive Financial and Wallet Tool Privileges Exposed to the Agent
workspace-template/README.md:58Plaintext Persistent Storage of the OpenPump API Key
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Or add it to your ~/.openclaw/.env file for persistence:
echo 'OPENPUMP_API_KEY=op_sk_live_YOUR_KEY_HERE' >> ~/.openclaw/.env
The document declares a user-supervised execution model requiring approval before trades, but elsewhere defines executable workflows that proceed directly to buy-token/sell-token. In a high-risk trading skill with custody over wallets and token transfers, this inconsistency can cause an agent to execute financial transactions without fresh user consent.
This section says the agent must always get explicit approval before trading, but the later operational workflow omits that gate and can be followed mechanically by an agent. The contradiction is dangerous because trade execution on pump.fun is irreversible and can rapidly lose funds in volatile memecoin markets.
The same approval language is undermined for sells, especially because the document also prescribes automatic exits like stop-losses and time-decay liquidations. Without strict authorization semantics, an agent may liquidate positions or transfer value based on inferred policy rather than confirmed user intent.
The skill prominently advertises wallet creation and management but does not clearly disclose up front that these are custodial, platform-managed wallets with associated custody and key-management risks. Users may assume they control private keys directly or misunderstand the trust model, which is especially dangerous in a crypto context involving fund transfers, trading, and automated strategies.
The invocation guidance is overly broad because it tells the agent to use the skill for essentially anything involving pump.fun tokens, bundle launches, Jito bundles, and even spam launches. In a high-risk financial skill that can launch tokens, transfer funds, and run autonomous trading actions, broad triggers increase the chance of inappropriate invocation, accidental financial operations, or use in contexts where the user did not explicitly request these dangerous actions.
The heartbeat instructs the agent to run automatically every 30 minutes and explicitly allows trade execution without per-action user approval if the user has previously given broad standing instructions such as auto-executing stop-losses. In a skill that can sell assets and manage wallets, this creates meaningful autonomous financial decision-making risk: stale consent, ambiguous scope of prior authorization, or misclassification of market conditions could trigger irreversible trades without contemporaneous confirmation.
This checklist runs automatically every 30 minutes when OpenClaw fires the heartbeat timer. Execute every step in order. Do not skip steps even if the previous heartbeat was recent.
> **Important:** All sell/buy actions identified during the heartbeat must be **presented to the user for approval** before execution, unless the user has granted explicit standing instructions for automated exits (e.g., "auto-execute stop-losses").
## Step 1: Check All Open Positions
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.
## What This Agent Does NOT Do
- Create new tokens (tools are available but not part of the trading strategy)
- Use multi-wallet bundle operations (single-wallet trading only)
- Transfer SOL externally without explicit user instruction
- Override risk parameters without explicit user instruction
The skill advertises real-money blockchain operations including token launches, trading, transfers, market making, sniping, stop-loss automation, and spam launches without any safety notice about irreversible transactions, custody implications, slippage, or loss of funds. In the context of an agent skill, this omission is dangerous because users may treat tool invocation as low-risk automation when it can trigger immediate on-chain actions and financial loss.
The documentation recommends persisting a live API key in an environment variable or a long-lived local env file, which increases the exposure window if the workstation, shell history, logs, backups, or local files are accessed by other processes or users. Because this skill enables financial operations against custodial wallets and trading endpoints, compromise of the key could allow unauthorized trades, transfers, or other account actions.
1. Sign up or log in
2. Navigate to Dashboard > API Keys
3. Create a new key (starts with `op_sk_live_`)
Set it as an environment variable:
The phrase permitting 'auto-execute stop-losses' introduces autonomous decision-making over financial transactions. While framed as an exception, it still enables the agent to act without per-trade confirmation, which is risky in volatile markets and especially sensitive because wallet tools can directly move user assets.
Then **wait for user confirmation** before calling `buy-token`, `sell-token`, `transfer-sol`, or `transfer-token`.
The only exception: if the user has explicitly granted standing instructions (e.g., "auto-execute stop-losses"), follow those instructions.
After every trade, report:
- Entry price and amount
The buy workflow is written as an executable runbook and includes a direct buy-token step after checks, but does not include an approval checkpoint in the procedure itself. Agents often prioritize concrete stepwise instructions, so omission of the warning in the operative sequence increases the chance of unauthorized purchases.
The sell workflow directs a full-position exit with tokenAmount: "all" and lacks an explicit warning that the action is irreversible and authorization-dependent. In a custodial trading context, a mechanical liquidation procedure without a confirmation gate can cause unintended loss realization or disputes over agent authority.
The file explicitly states that all tools communicate using OPENPUMP_API_KEY but provides no warning about credential sensitivity, storage, logging, or sharing. In a high-risk trading/custodial-wallet skill, this omission increases the chance that users or downstream agents mishandle the API key, which could enable unauthorized trading, wallet actions, or account abuse if exposed.
The poll-job documentation says to use cancel-job after spam-launch, but the file later documents a dedicated cancel-spam-launch tool for that workflow. This is a direct contradiction in the skill's own usage guidance and could cause an agent to invoke the wrong cancellation tool.
No suspicious patterns detected.