T09 · Insecure Skill Coding Practices
- Location
scripts/paytrigo.mjs:7- Finding
Hard-Coded Live PayTrigo API Credentials
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This payment skill is mostly coherent, but it embeds live payment API keys and can sign blockchain transactions with a user's wallet without enough validation or confirmation.
Install only after the publisher removes and rotates the embedded PayTrigo keys, requires user- or deployment-provided secrets, adds decoded transaction validation and explicit confirmation for bot payments, stops accepting raw private keys/passphrases on the command line, and pins dependencies with a lockfile. Use a dedicated low-balance wallet if testing.
scripts/paytrigo.mjs:7Hard-Coded Live PayTrigo API Credentials
scripts/moltbot-bot-flow.mjs:154Unvalidated Signing of API-Supplied Blockchain Transactions
scripts/moltbot-human-flow.mjs:156Checkout Authorization Tokens Disclosed Through Standard Output
scripts/moltbot-bot-flow.mjs:98Private Keys and Wallet Passphrases Accepted Through Process Arguments
package.json:5Non-Reproducible Dependency Installation Without a Lockfile
The skill explicitly states that a platform API key is embedded in the helper script and promotes 'no-setup' immediate use. Embedding live credentials in distributable skill content is dangerous because any user or downstream agent can extract and abuse the key to create invoices, misuse platform resources, or impersonate legitimate payment activity.
The skill normalizes passing private keys on the command line and handling encrypted wallets/passphrase files without prominent safety guidance. Command-line private keys, local plaintext key files, and passphrase files are commonly exposed through shell history, process lists, logs, backups, or weak filesystem permissions, creating a realistic path to wallet compromise and fund theft.
The script hard-codes a live PayTrigo secret key directly in source, which exposes reusable production credentials to anyone who can read the file, logs, repository history, or packaged skill contents. Because this skill is explicitly designed to create payment invoices, the embedded key enables unauthorized API use, invoice creation, abuse of the merchant account, and possible downstream financial or operational damage.
After obtaining remote transaction instructions, the script immediately sends on-chain approve and pay transactions with the user's wallet and waits for confirmation, without any interactive confirmation or final review of recipient, amount, contract target, or calldata. In a payment skill context, this is especially dangerous because a mistaken invocation, compromised API response, or mis-specified recipient can directly cause irreversible loss of funds or unsafe token approvals.
The script embeds a live PayTrigo secret key directly in source code and uses it to create invoices against a production payment API. Any user who can read the skill, logs, repository, or packaged artifact can extract the credential and create or query payment objects on the associated account, leading to unauthorized API use, billing abuse, and broader account compromise.
A hard-coded live API credential in source code is a direct secret exposure vulnerability. Because this skill is specifically designed to create and verify PayTrigo payments, the exposed key is especially dangerous: anyone with access to the script can invoke privileged payment API operations in the production environment.
The script embeds and actively uses a live PayTrigo secret key, which gives anyone with access to the skill source immediate authenticated access to the payment API. In a payment-creation helper, this is especially dangerous because the key can be reused outside the intended workflow to create, inspect, or manipulate payment-related resources, and hard-coding prevents proper key rotation and scope control.
The README explicitly instructs users to pass a raw private key on the command line (--pk 0xPRIVATE_KEY). Command-line secrets are commonly exposed through shell history, process listings, terminal logging, CI logs, and remote session tooling, which can lead to full compromise of the payer wallet and theft of funds. In this skill’s context, the secret is a blockchain private key, so exposure is especially dangerous because transactions are irreversible.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
echo "use-a-strong-passphrase" > passphrase.txt
chmod 600 passphrase.txt
The skill advertises and instructs use of network and shell-capable scripts, but does not declare any tool scope or permission boundaries. That omission increases the chance an agent will run commands or make outbound requests without explicit user awareness, which is especially risky in a payment-handling skill.
The request helper sends invoice creation and payment-intent submission data to an external API, including recipientAddress, metadata, txHash, and payerAddress. The script contains no visible disclosure that these details will be transmitted to a third-party service, beyond the implementation itself.
The advertised capability includes payment verification, but the implemented flow only creates invoices, retrieves payment intents, signs blockchain transactions, and submits payment execution. This mismatch is security-relevant because users or orchestrators may invoke the skill expecting a read-only verification action, while the code performs state-changing financial operations that can spend funds.
The script performs a real payment-related API action as soon as the human command is run, creating a live invoice before any explicit confirmation prompt or strong warning. In an agent-skill context, this increases the risk of accidental or automated payment operations being triggered by misunderstood instructions, unsafe defaults, or adversarial task inputs.
The CLI accepts passphrases directly via --passphrase and private keys via --pk, which can expose secrets through shell history, process listings, terminal logging, CI job output, and agent telemetry. In an agent-driven payment skill, this is especially risky because wallet credentials protect real funds and may be handled in automated environments where command invocations are widely observable.
The manifest describes a skill for creating or verifying PayTrigo payments on Base/USDC without webhooks, which suggests payment operations. This script instead creates new Ethereum wallets, imports private keys, encrypts them, and writes wallet, address, passphrase-derived, and recipient state to local files, which is a separate wallet provisioning/storage capability not described in the manifest.
Creating random wallets and importing raw private keys are powerful key-management capabilities distinct from creating or verifying payments. A payment-focused skill may need to use an existing wallet, but provisioning and importing sensitive key material is not obviously required by the manifest's narrowly stated purpose.
The script's messaging implies the API key should come from PAYTRIGO_API_KEY, but the actual code always uses the embedded default key instead. This mismatch can mislead operators into thinking they control authentication through environment configuration when in reality the exposed built-in credential is always used, undermining secret management and incident response.
The script creates invoices and submits payment intent/status requests to a remote payment API, transmitting recipient addresses, transaction hashes, payer addresses, and metadata. Although these operations are central to the tool, the file provides no explicit user-facing warning or confirmation that payment-related data will be sent to an external service.
The dependency version for ethers is specified with a caret range, which permits automatic installation of newer minor and patch releases. This can introduce supply-chain risk or unexpected behavior changes if a compromised or incompatible release is published, especially in a payment-related skill that interacts with Base/USDC transactions.
"private": true,
"type": "module",
"dependencies": {
"ethers": "^6.0.0"
}
}
When --recipient is not supplied, the script automatically reads a recipient address from .openclawbot/recipient.txt or another provided file path. This local data access is not described in any warning or explanatory comment, which can surprise users who do not expect file-based input to be used implicitly.
Detected: suspicious.exposed_secret_literal