ClawHub
Back to skill

Security audit

Maestro Api

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent for paid Maestro API calls, but it gives an agent under-scoped authority to use a wallet signer and make additional credit purchases after only an initial confirmation.

Review this skill carefully before installing. Use a constrained wallet signer rather than pasting a raw private key, fund it only with the amount you are willing to spend, and require explicit approval for every payment, recipient, token contract, network, and amount.

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 (1)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:12
Finding

Repeated Wallet Payments Lack Per-Transaction Approval and Cumulative Spending Limits

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:12-20, SKILL.md:48-58, references/siwx-x402.md:86-91, and references/siwx-x402.md:219-226
Vulnerability Type: Insufficient authorization controls for cryptocurrency payments
Risk Level: Medium

The Skill permits an Agent to sign cryptocurrency payment authorizations using terms supplied by a remote 402 response. User confirmation is required only before the first paid mainnet request; subsequent credit purchases can occur without renewed approval or a cumulative spending limit.

Vulnerable Code Snippets

SKILL.md:12-20:

markdown
1. Resolve the exact operation page in `docs.gomaestro.org`.
2. Read the page's `.md` form and use its `OpenAPI` block as the source of truth.
3. Build the request URL from `servers:` plus the operation path.
4. Send the real request with no auth or payment headers.
5. If the response is `200`, return the data.
6. If the response is `402` with `extensions.sign-in-with-x`, sign the SIWX challenge and retry the exact same request with `sign-in-with-x`.
7. If that retry returns `200`, return the data.
8. If that retry returns `402` plus `Authorization: Bearer <jwt>`, buy credits from the latest `accepts[]` entry and retry the exact same request with `Authorization` and `X-PAYMENT`.
9. Reuse the JWT for follow-up queries until it expires or Maestro asks for more credits.

SKILL.md:48-58:

markdown
## Request Rules

- Keep method, path, query parameters, and body unchanged across the unauthenticated request, the SIWX retry, and the paid retry.
- Always use the latest `402` response for `supported_chains`, `accepts[]`, `asset`, `pay_to`, and price limits.
- Confirm before the first paid mainnet request.
- If a paid retry still fails, report:
  - docs page used
  - selected network
  - selected amount
  - signer address
  - minimal next action

references/siwx-x402.md:86-91:

m
...[truncated 4464 chars]
Remediation
View remediation

Remediation Suggestions

  1. Require explicit user approval before every newly signed payment authorization, including retries that use a new nonce or altered authorization.
  2. Display the exact chain, token contract, recipient, amount, authorization validity period, and cumulative session spend before requesting approval.
  3. Require the user to choose or explicitly approve the exact amount. Do not let the Agent independently select any amount merely because it falls within server-provided bounds.
  4. Add user-configurable per-payment and cumulative session spending caps. Stop immediately when either cap would be exceeded.
  5. Set a maximum number of purchases per task and require renewed approval before extending that limit.
  6. Allowlist expected chain IDs, verified USDC contracts, Maestro API hosts, and known payment recipients.
  7. Treat any change in network, asset, pay_to, or price as a new transaction requiring separate approval.
  8. Validate payment terms against both the latest response and local policy. Remote responses must not be the sole source of authorization policy.
  9. Prefer a restricted wallet signer with chain, token, recipient, amount, and time constraints instead of accepting an unrestricted raw private key.
  10. Remove signer access and clear retained JWT or payment state when the requested operation is complete.
  11. Reusing an identical encoded payment payload for a network retry may be allowed only when the user previously approved that exact payload. Any changed field or new authorization must trigger another confirmation.

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • 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 (1)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The skill explicitly asks for a PRIVATE_KEY or wallet signer to complete live SIWX signing and x402 payments, but it provides no user-facing warning about the sensitivity of that credential or any guardrails around how it should be supplied, stored, or scoped. In a skill that performs external HTTP requests and payment flows, normalizing direct private key access increases the chance of credential exfiltration, misuse, or unsafe operator behavior even if the skill does not overtly instruct exfiltration.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.