T09 · Insecure Skill Coding Practices
- Location
scripts/gstable-ai-payment.py:541- Finding
Remote API Data Controls Arbitrary Transactions and Unlimited Token Approvals
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a disclosed crypto payment tool, but it should be reviewed carefully because it can sign live transactions and grant broad token approvals automatically.
Install only if you are comfortable giving this skill control of a wallet private key. Use a dedicated low-balance wallet, avoid the one-command pay path until you have reviewed the payment details, verify the chain, token, recipient, spender, and amount before every approval or transaction, and do not set GSTABLE_API_BASE_URL or RPC URLs to endpoints you do not fully trust.
scripts/gstable-ai-payment.py:541Remote API Data Controls Arbitrary Transactions and Unlimited Token Approvals
scripts/api.py:11Security-Sensitive Payment API Endpoint Can Be Redirected to an Arbitrary Origin
pyproject.toml:8Security-Critical Dependencies Are Not Reproducibly Pinned
The execute command signs and broadcasts an arbitrary transaction to any provided destination address with arbitrary calldata, using the configured wallet private key. That capability exceeds the stated payment-specific purpose and allows any caller or integrating agent to repurpose the skill as a general blockchain transaction signer, which could transfer assets, approve spenders, or invoke malicious contracts if untrusted inputs are passed through.
The execute path submits a live on-chain transaction immediately after building and signing it, with no explicit consent checkpoint, transaction summary, or warning that real funds or approvals may be affected. In agentic contexts, this is especially dangerous because upstream prompts, tool-use decisions, or compromised services could cause irreversible blockchain actions without meaningful user awareness.
The approve command defaults to MAX_UINT256 when no amount is supplied, creating an infinite ERC20 allowance without an explicit warning or confirmation. Infinite approvals are a well-known high-risk pattern because if the approved spender is malicious, compromised, or later upgraded, the wallet's token balance can be drained long after the initial approval.
The pay command chains discovery, session creation, payment preparation, optional token approval, and final transaction submission into one automatic flow with no explicit consent checkpoint between steps. Because it can both create broad token allowances and broadcast a transaction based on externally sourced link/session data, this design amplifies the blast radius of any malicious payment link, compromised backend response, or agent mistake.
The skill requests and uses a highly sensitive environment variable (WALLET_PRIVATE_KEY) and performs networked blockchain operations, but it does not declare an explicit tool scope or permissions boundary. In an agent setting, this increases the chance that the skill is invoked with broader-than-necessary capabilities, enabling unintended fund-moving actions or secret exposure through loosely governed execution.
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.
## Features
- 🔗 Retrieve payment link details and supported tokens
- 📝 Create payment sessions (EIP-712 signatures)
- 🔍 Query payment session status
- 💰 Check native and ERC20 balances
- 💳 Prepare payments and generate on-chain transaction calldata
The feature list advertises automatic token approval and on-chain execution without prominently warning that approvals can authorize token spending and that blockchain transactions are generally irreversible. In an autonomous-agent context, this can normalize dangerous fund movement behavior and cause users or orchestrators to trigger spending without fully understanding the consequences.
The quick-start examples encourage immediate use of the one-command pay flow, which can create sessions, approve tokens, and submit live on-chain transactions without an explicit warning at the point of use. This is especially risky for agent-driven workflows because a copied example may trigger real asset transfers with minimal operator review.
This function sends a signed EIP-712 message and signature to an external payment service, but the client code provides no user-facing disclosure, consent checkpoint, or trust boundary documentation before transmitting sensitive authorization material. In a payment skill, signatures can authorize financial actions or reveal reusable payment metadata, so silently forwarding them to a remote API materially increases the risk of unintended payment authorization or misuse if the service, configuration, or surrounding workflow is compromised.
This payment preparation call transmits signed payload data to an external service to obtain calldata, again without any visible disclosure or consent mechanism in the client. Because this skill's purpose is cryptocurrency payments, signed messages are especially sensitive: sending them to a third party can expose authorization artifacts and enable harmful downstream transaction preparation if users are unaware or if the endpoint is altered.
The manifest describes discovering, negotiating, and executing cryptocurrency payments, which does justify payment-related network and transaction logic. However, directly ingesting a raw private key from environment variables is a distinct sensitive capability involving custody of signing credentials, and that custody expectation is not stated in the manifest text.
The approve command exposes a generic ERC20 approval primitive that can approve any spender for any token, independent of a validated payment session. In a payment skill, this broad authority lets the skill grant spending rights to arbitrary contracts, and because approvals often persist, a malicious or mistaken spender could later drain tokens from the wallet up to the approved amount.
Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
No suspicious patterns detected.