T09 · Insecure Skill Coding Practices
- Location
scripts/buy.js:9- Finding
Unrestricted API endpoint can receive credentials and issue wallet-signed payment challenges
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is for blockchain-backed purchases, but it handles wallet/API secrets and payment endpoints too loosely for automatic installation.
Review this skill carefully before installing. Use only a dedicated low-value wallet, prefer testnet, verify the LobPay API URL, avoid entering private keys in shared shells or CI logs, and do not let an agent run purchase commands without a clear item, amount, merchant, network, and endpoint confirmation.
scripts/buy.js:9Unrestricted API endpoint can receive credentials and issue wallet-signed payment challenges
scripts/register.js:14Wallet private key and API key are exposed through command-line arguments and plaintext local storage
scripts/package.json:6Security-critical dependencies use floating version ranges without a lockfile
The skill description presents purchasing and payment capabilities without a prominent warning that actions may result in real merchant payments and irreversible blockchain transactions. Because the skill references Base Mainnet support and local private key usage, the lack of an upfront warning raises the chance that users or calling agents will treat it like a harmless informational tool and trigger costly actions.
The default API base URL is http://localhost:3000, and the script sends a Bearer API key plus payment-related request data to that endpoint. Using cleartext HTTP, even as a default, creates a risk of credential exposure or request tampering if the URL is changed to a non-local host, forwarded, proxied, containerized, or otherwise used outside a strictly local trust boundary.
Accepting a private key on the command line exposes it to shell history, process listings, audit logs, and CI/job telemetry. That can leak the wallet secret to other local users, administrators, logging systems, or monitoring tools, enabling unauthorized transactions and account takeover.
The script writes a raw private key and API key to a predictable file in the user's home directory without warning, encryption, or permission hardening. If the host is multi-user, backed up, compromised by malware, or if file permissions are too broad, these secrets can be recovered and used to impersonate the agent or steal wallet-controlled assets.
The trigger list includes very broad commerce terms such as "Buy," "Purchase," "Pay," and "Checkout," which can cause the skill to activate in contexts where the user did not intend to initiate a blockchain-backed payment workflow. In a skill that can lead to real purchases and on-chain transactions, overly broad invocation materially increases the risk of unintended or premature payment actions.
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.
## 💰 X402 Payment Flow
1. **Checkout** → Get merchant wallet + pricing
2. **Sign** → Create X402 payment header
3. **Purchase** → Send to `/agents/purchase` with payment proof
4. **Confirm** → Transaction recorded on Base
The documentation describes an authenticated purchase endpoint that triggers X402 payment signing, on-chain settlement, and transaction recording, but it does not prominently warn that these actions can transfer funds and may be irreversible. In an agent-skill context, this omission is dangerous because an integrator or autonomous agent may treat the endpoint as a routine API call and execute real purchases without sufficient user confirmation or safety gating.
The documentation instructs implementers to verify signatures, transfer tokens, and record transactions, but it does not warn that these actions move real funds and may be irreversible on-chain. In a payment-protocol integration guide, omission of financial-risk messaging can lead developers or users to test against mainnet, authorize token spending, or trigger unintended transfers without appreciating the consequences.
The script performs a real paid purchase immediately after fetching checkout information, with no explicit confirmation step or spending guard before calling the payment-enabled purchase endpoint. In a CLI skill that can be invoked by an agent or automation, this increases the risk of accidental or manipulated purchases, especially if product ID, quantity, or API base are influenced by untrusted input or environment configuration.
This code reads a private key from the user's config and immediately derives an account from it, which is a sensitive credential access operation. Although the script logs purchase activity, it does not disclose that it will access wallet credentials from disk or explain that behavior in comments/docstrings at this point.
With no manifest available, this file appears from its code and user-facing output to be a local purchase-history viewer: it reads ~/.lobpay/history.json and prints transactions. However, it also imports axios and constructs an API base URL from an environment variable, despite never using network access in the implemented behavior, which introduces an unjustified capability relative to the script's apparent purpose.
The dependency uses a caret range (^2.0.0), which allows newer minor and patch releases to be installed over time. That weakens build reproducibility and can unintentionally introduce vulnerable or malicious upstream changes into the agent skill's supply chain.
"description": "LobPay Agent Skill - X402 commerce on Base",
"type": "module",
"dependencies": {
"@x402/fetch": "^2.0.0",
"@x402/evm": "^2.0.0",
"viem": "^2.0.0",
"axios": "^1.6.0"
The dependency is version-ranged with a caret, so future installs may resolve to different releases than originally tested. In an agent that handles commerce and EVM interactions, this creates unnecessary supply-chain exposure if an upstream release introduces insecure behavior.
"type": "module",
"dependencies": {
"@x402/fetch": "^2.0.0",
"@x402/evm": "^2.0.0",
"viem": "^2.0.0",
"axios": "^1.6.0"
}
Using ^2.0.0 for viem permits automatic drift to later compatible releases, reducing reproducibility and increasing supply-chain risk. Because this package is likely involved in blockchain/EVM operations, unexpected dependency changes could affect transaction handling or security-sensitive logic.
"dependencies": {
"@x402/fetch": "^2.0.0",
"@x402/evm": "^2.0.0",
"viem": "^2.0.0",
"axios": "^1.6.0"
}
}
Axios is not pinned to an exact version, so installs may pick up later 1.6.x releases without explicit review. This is more dangerous here because axios has a history of security advisories, making unreviewed drift more likely to introduce exploitable client-side or SSRF-related issues into the skill.
"@x402/fetch": "^2.0.0",
"@x402/evm": "^2.0.0",
"viem": "^2.0.0",
"axios": "^1.6.0"
}
}
The manifest references axios with a non-exact version while the package has multiple known advisories, so the actual installed version cannot be verified as safe. In a network-facing commerce agent, an affected axios release could expose the skill to SSRF, request smuggling, credential leakage, or similar HTTP-client abuses depending on how it is used elsewhere.
Detected: suspicious.env_credential_access