Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent payments skill, but it asks for payment API authority while exposing dashboard passwords in normal output and encouraging broad customer data collection without enough controls.
Review before installing. Use a narrowly scoped Obverse API key, avoid overriding OBVERSE_API_URL except to a trusted HTTPS or local development endpoint, do not share generated dashboard passwords in group chats or logs, and collect customer or contributor data only with explicit consent and a clear retention policy. Prefer verified OpenClaw and ClawHub installation methods instead of running remote scripts or unpinned global packages.
DEPLOYMENT.md:83Unverified Remote Installation Script Executed Directly by Bash
obverse-cli.js:10API Key Can Be Sent to an Arbitrary or Plaintext Configured Endpoint
obverse-cli.js:548Temporary Dashboard Credentials Are Exposed Through Standard Output and Agent Messages
obverse-cli.js:106Payment Amounts and Transaction Fields Lack Client-Side Validation
DEPLOYMENT.md:456Unpinned Global Installation of a Third-Party Publishing CLI
Piping a remote script directly into bash executes unverified code from the network with the user's privileges, creating a supply-chain compromise path if the host, TLS termination, DNS, or distribution channel is tampered with. In a deployment guide for a payment-related skill, this is especially risky because operators are likely to run setup commands on systems that also hold API keys, bot tokens, and payment infrastructure secrets.
brew install openclaw
# Linux (Ubuntu/Debian)
curl -fsSL https://openclaw.ai/install.sh | bash
# Or download from GitHub
# https://github.com/openclaw/openclaw/releases
The command chaining pattern here directly feeds downloaded content into a shell interpreter, eliminating any opportunity for inspection and magnifying the impact of a compromised upstream source. Because this skill handles payments and directs users to configure sensitive credentials, successful exploitation could lead to theft of API keys, bot tokens, payment redirection, or broader host compromise.
brew install openclaw
# Linux (Ubuntu/Debian)
curl -fsSL https://openclaw.ai/install.sh | bash
# Or download from GitHub
# https://github.com/openclaw/openclaw/releases
This second mismatch finding points to the same core issue: the skill markets itself as an end-to-end payments platform with invoices, receipts, dashboards, and messaging-platform support, but the provided content primarily documents a narrower API client pattern. Misrepresentation of functionality increases security risk because users cannot accurately assess data flows, trust boundaries, or whether sensitive operations are actually implemented safely.
This second mismatch finding points to the same core issue: the skill markets itself as an end-to-end payments platform with invoices, receipts, dashboards, and messaging-platform support, but the provided content primarily documents a narrower API client pattern. Misrepresentation of functionality increases security risk because users cannot accurately assess data flows, trust boundaries, or whether sensitive operations are actually implemented safely.
The skill explicitly instructs the agent to expose dashboard login credentials and sensitive customer/payment access details in a chat response. In shared or persisted chat environments, this can directly leak account access and PII to unauthorized parties, making the risk concrete rather than hypothetical.
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.
Create API keys in your Obverse system:
// In your backend, add API key generation endpoint
The guide instructs operators to add analytics that capture agent identifiers, amounts, currencies, chains, and timestamps, but it does not warn users that payment metadata and identifiers will be transmitted to the backend and stored for analytics. In a payments skill, that omission matters because merchants and customers may assume only operational payment processing occurs, while the deployment guidance expands data collection without consent, minimization, or retention guidance.
The README promotes payment handling, invoices, wallet balances, and messaging-platform use, but it does not clearly warn users that the skill processes sensitive financial and potentially personal data. Without explicit notice, users may expose wallet information, transaction metadata, customer identifiers, or invoice details in contexts where retention, logging, or third-party access is not understood.
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.
- ✅ Generate payment links and QR codes
- ✅ Accept USDC/USDT on Solana and Monad
- ✅ Track payment status in real-time
- ✅ Create invoices automatically
- ✅ Check wallet balances
- ✅ Multi-platform: Telegram, WhatsApp, Discord, Signal
- ✅ Low transaction fees (0.5-1.5%)
The command examples are phrased as ordinary natural-language requests like "What's my balance?" and "List recent payments" without any explicit activation boundary, confirmation step, or scoped intent syntax. In a multi-agent or chat environment, this increases the chance of accidental invocation and unintended access to payment history or financial actions from routine conversation.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# Install curl (required dependency)
# Ubuntu/Debian:
sudo apt-get install curl jq
# macOS:
brew install curl jq
The skill declares no explicit tool scope or allowed-tools despite clearly requiring environment access, network calls, and shell execution. In an agent environment, missing capability boundaries can lead to overbroad execution privileges and make it harder for operators to reason about what the skill may do with secrets and external endpoints.
The skill strongly encourages collecting customer email, name, phone, and arbitrary custom fields, but provides no privacy notice, consent guidance, retention limits, or data handling safeguards. In a payments context, combining financial activity with personal data materially raises privacy and compliance risk.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Register from any platform (no Telegram required!)
curl -X POST https://obverse.onrender.com/api-keys/register \
-H "Content-Type: application/json" \
-d '{"username": "your-agent-name"}'
The examples show dashboard usernames and passwords being returned directly and normalized as routine output, without warning that these credentials grant access to customer and payment data. Encouraging agents to emit live credentials into chats creates a high likelihood of accidental disclosure through logs, screenshots, channel members, or prompt history.
The workflow promotes extracting customer email lists from payment data for marketing, but does not mention consent, opt-in status, or purpose limitation. Using payment-collected personal data for marketing without controls can create privacy violations, regulatory exposure, and user harm.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Check your API key
echo $OBVERSE_API_KEY
# Register for a new key:
curl -X POST https://obverse.onrender.com/api-keys/register \
-H 'Content-Type: application/json' \
-d '{"username": "your-agent-name"}'
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
"envVars": {
"OBVERSE_API_KEY": {
"required": true,
"description": "Your Obverse API key. Register programmatically: curl -X POST https://obverse.onrender.com/api-keys/register -H 'Content-Type: application/json' -d '{\"username\": \"your-agent-name\"}'"
},
"OBVERSE_API_URL": {
"required": false,
The submit-payment path transmits customer email in customerData without any explicit warning, consent checkpoint, or disclosure in command output. In an agent-driven environment, silent forwarding of personal data to a third-party payment platform can violate privacy expectations and facilitate unnoticed data sharing.
The skill adds product-sales and fundraiser commands that automatically collect customer or contributor identity fields such as email and name, which goes beyond a narrow payment-processing function and expands the data footprint. In an agent context, this can enable silent harvesting of personal data under the guise of creating payment links, especially because the behavior is framed as a convenience feature rather than a privacy-sensitive operation.
The analytics and contributor-listing functionality exposes payer addresses, contribution history, totals, and activity timelines, creating profiling capability beyond basic payment handling. In a messaging-agent setting, this materially increases privacy risk because the tool can be used to enumerate and analyze contributors without any user-facing warning or access-control check in the CLI itself.
The contributor-listing feature returns payer wallet addresses, contribution totals, timestamps, and transaction references with no privacy warning or minimization. That enables deanonymization or profiling of donors/customers, which is especially sensitive in payment contexts where users may not expect broad disclosure of participation history.
The generate-dashboard command returns temporary dashboard credentials directly in CLI output, along with login instructions, but does not warn that these are sensitive secrets that grant access to payment analytics. In agent or logged-shell environments, this can lead to credential leakage through logs, chat transcripts, terminal history, or downstream tool capture.
The help text explicitly advertises collecting 'ANY data you need' including phone, address, and company information, signaling broad arbitrary data capture unrelated to a payments-only description. This increases the risk that downstream agents or users will normalize overcollection of sensitive personal information without necessity, notice, or purpose limitation.
The manifest describes a very broad 'complete stablecoin payment solution' for AI agents without defining activation boundaries, user consent requirements, or task-scoping constraints. In a payments skill, ambiguous scope increases the chance an agent will invoke financial actions in inappropriate contexts or without sufficiently explicit user intent, which raises misuse and accidental transaction risk.
Detected: suspicious.env_credential_access, suspicious.exposed_secret_literal