T09 · Insecure Skill Coding Practices
- Location
SKILL.md:135- Finding
Wallet Transactions Are Unrestricted by Default
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 135–151
Vulnerability Type: Default-allow authorization policy for financially sensitive operations
Risk Level: Highmarkdown ## Policies The wallet owner controls what the agent can do by setting policies via the claim URL. If a transaction violates a policy, the API will reject it or require human approval via Telegram. | Policy | What it does | |--------|-------------| | **Address allowlist** | Only allow transfers/calls to specific addresses | | **Token allowlist** | Only allow transfers of specific ERC-20 tokens | | **Function allowlist** | Only allow calling specific contract functions (by 4-byte selector) | | **Spending limit (per tx)** | Max USD value per transaction | | **Spending limit (daily)** | Max USD value per rolling 24 hours | | **Spending limit (weekly)** | Max USD value per rolling 7 days | | **Require approval** | Every transaction needs human approval via Telegram | | **Approval threshold** | Transactions above a USD amount need human approval | If no policies are set, all actions are allowed by default. Once the owner claims the wallet and adds policies, the agent operates within those boundaries.Technical Analysis
The wallet uses an insecure default-allow authorization model. Until the owner claims the wallet and configures policies, the bearer API key can authorize every documented operation, including token transfers, swaps, and arbitrary smart-contract calls.
This creates a vulnerable period between wallet creation and policy configuration. The design relies on the owner completing an optional, out-of-band claim process rather than enforcing safe restrictions at wallet creation. Because the same bearer credential controls financially sensitive operations, compromise or misuse of that credential during this period can result in unrestricted transaction execution.
The risk is amplified by the documented arb ...[truncated 1813 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the default-allow model with a default-deny policy. Reject all state-changing wallet operations until the wallet has been claimed and explicitly configured.
- Require mandatory human approval for every transaction before policy setup is complete.
- Prevent funding or clearly mark the wallet as inactive until ownership claim and policy initialization have succeeded.
- Apply conservative policies automatically at creation, including zero or minimal spending limits, empty destination and function allowlists, and disabled arbitrary contract calls.
- Issue narrowly scoped credentials rather than one bearer key with access to every wallet operation. Separate read-only balance access from transfer, swap, and arbitrary-call permissions.
- Support credential rotation, revocation, expiration, and secure server-side audit logging.
- Require explicit confirmation when enabling arbitrary transaction functionality and validate destination addresses, function selectors, calldata, value, and chain identifiers against owner-approved rules.
- Clearly instruct users not to deposit assets until the wallet has been claimed and all intended restrictions have been verified.