ClawHub
Back to skill

Security audit

clawdio

Security checks for vulnerabilities and agentic risk

Overview

The skill is a disclosed paid audio-intelligence API, but it gives agents automatic USDC purchase ability without clear per-purchase consent or spending controls.

Install only if you are comfortable connecting a funded x402 wallet to this service. Use a dedicated low-balance wallet, require manual approval before every purchase, avoid wallet-enabled crawling or self-discovery, and treat returned transcripts and speaker identities as potentially sensitive personal data.

A.I.G

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:104
Finding

Automatic Payment Authorization Without Explicit Per-Purchase Approval

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 41 and 104–108
Vulnerability Type: Automatic financial authorization with insufficient validation and user confirmation
Risk Level: High

Relevant Code Snippet:

markdown
The x402 payment is handled **automatically** via the `PAYMENT-SIGNATURE` header — your wallet provider manages the signing and settlement. You do not need to construct payment transactions manually.
markdown
On first request without payment, the server returns **HTTP 402 Payment Required** with a `PAYMENT-REQUIRED` header. Your x402 wallet automatically:

1. Reads the payment requirements from the 402 response
2. Signs a USDC payment on Base Mainnet
3. Retries the request with the `PAYMENT-SIGNATURE` header
4. Receives the full content after payment settles

The same behavior is reinforced at lines 240–241:

javascript
// The agent can now browse and purchase from Clawdio automatically.
// Point it at https://clawdio.vail.report/ and it will self-discover the API.

Technical Analysis

The Skill directs an agent to give an x402 wallet authority to automatically sign and settle USDC payments in response to requirements supplied by a remote server. The documented flow does not require explicit user confirmation for each purchase and does not specify enforcement of:

  • A maximum payment amount
  • A cumulative session spending limit
  • Verification of the payment recipient
  • Validation of the expected product identifier
  • Validation of the chain and asset immediately before signing
  • Protection against repeated payment requests
  • Confirmation that a payment originated from an intentional user purchase

The PAYMENT-SIGNATURE is necessarily sent over the network as part of the declared x402 payment protocol. The audited file does not show raw wallet secrets or CDP API credentials being transmitted. Nevertheless, automatic signing grants the remo ...[truncated 1566 chars]

Remediation
View remediation

Remediation Suggestions

  • Require explicit, informed user approval before every paid request.
  • Before approval, display the exact amount, token, chain ID, recipient, product identifier, and originating host.
  • Compare payment requirements against locally configured expectations rather than trusting values returned solely by the remote server.
  • Reject payments whose amount differs from the approved price or exceeds a strict maximum.
  • Restrict payments to USDC on Base Mainnet and verify the expected token contract and recipient.
  • Introduce per-transaction and cumulative session spending limits.
  • Separate free discovery and catalog browsing from wallet-enabled purchase operations.
  • Disable automatic payment handling during API self-discovery.
  • Require a fresh confirmation if any payment field changes after initial approval.
  • Record payment receipts and product identifiers locally to prevent unintended repeat purchases.
  • Use a dedicated low-balance wallet rather than a broadly funded operational wallet.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:84
Finding

Financially Consequential Purchase Implemented Through HTTP GET

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 84–91, 96–108, and 267–269
Vulnerability Type: Unsafe HTTP method semantics for payment-triggering operations
Risk Level: Medium

Relevant Code Snippet:

json
"purchase_instructions": {
  "steps": [
    "Select a product from the list above",
    "Make an HTTP GET request to the product's purchase.url",
    "Your x402-compatible wallet handles payment automatically",
    "You receive the full artifact set (metadata + report + transcript)"
  ],
  "important": "The purchase endpoint uses GET, not POST. Save the artifacts — repurchase is required for repeat access."
}

The requirement is repeated at lines 267–269:

markdown
- **GET not POST:** The purchase endpoint uses `GET`. Do not send POST requests.
- **Base Mainnet only:** Payment is in USDC on Base Mainnet (eip155:8453).
- **Save your purchase:** Artifacts are not stored for you. Repurchase is required for repeat access.

Technical Analysis

HTTP GET is conventionally safe and idempotent and is commonly subject to automated behavior such as prefetching, retries, crawling, caching, link inspection, and repeated navigation. The documented endpoint uses GET for a financially consequential purchase flow and combines it with automatic x402 payment handling.

An unauthenticated GET initially returning HTTP 402 does not itself prove that every ordinary crawler or prefetcher can complete a payment. Payment requires an x402-enabled client with wallet authority. However, when the request is made through such a client, an automatic retry, prefetch, duplicate invocation, or agent navigation can progress from a nominally safe GET request to a settled payment.

The documentation also states that artifacts are not retained and that repeat access requires repurchase. No idempotency key, durable entitlement, transaction deduplication mechanism, or explicit confirmation step is documente ...[truncated 1300 chars]

Remediation
View remediation

Remediation Suggestions

  • Replace the purchase GET endpoint with POST or another method intended for state-changing operations.
  • Require an explicit purchase request body containing the product identifier and client-generated idempotency key.
  • Persist payment receipts and grant durable access to previously purchased artifacts.
  • Return the existing purchase result when the same idempotency key is reused.
  • Prevent wallet-enabled payment processing during catalog browsing, crawling, previews, or link prefetching.
  • Require explicit user confirmation immediately before the payment-capable request.
  • Disable automatic retries for payment requests unless the client can verify that the previous attempt did not settle.
  • Reconcile transaction hashes before initiating a replacement payment after network errors.
  • Avoid placing sensitive purchase state in URL query strings.
  • Clearly distinguish free, safe discovery endpoints from state-changing paid endpoints in both API design and client tooling.

SkillSpector

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The skill explicitly states that x402 payment is handled automatically via the PAYMENT-SIGNATURE header and later encourages agents to browse and purchase automatically, but it does not prominently require explicit user approval before funds are spent. In an agent setting, this can lead to unintended or repeated USDC expenditures, especially if the agent self-discovers the API and follows purchase links autonomously.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
90% confidence
Finding

The purchased output includes participant identities, Twitter handles, avatars, speaker-attributed quotes, and full timestamped transcripts, yet the skill does not present a prominent privacy, consent, or data-handling warning. This increases the risk of downstream privacy misuse, redistribution of personally identifiable conversational data, or use of sensitive speech content without adequate notice or policy constraints.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.