Back to skill

Security audit

Open Wallet

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent and transparent about wallet actions, but it exposes broad wallet-signing and transaction authority plus automatic result redirects that users should review carefully before installing.

Install only if you are comfortable with agents creating links that can ask your wallet to sign messages or submit transactions. Before opening any generated link, verify the chain, target address or contract, function, value or token amount, and whether the result will be redirected to another site. Avoid redirect_url for signatures unless the destination is trusted.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • 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
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:87
Finding
Sensitive Wallet Results Can Be Redirected to Arbitrary Destinations<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:21, 87-111` **Vulnerability Type**: Unrestricted transmission of wallet signatures and transaction results **Risk Level**: High ### Vulnerable Code Snippet ```markdown - `redirect_url` (optional): where to redirect after success/failure with the result. ``` ```markdown ### Option B: redirect_url (automatic return) If you include `redirect_url`, the app redirects after success or failure. It appends query params (default mode): - On success: - `resultType=string` and `result=<value>` OR - `resultType=json` and `result=<JSON.stringify(value)>` - On failure: - `error=<message>` Template mode (no bridge, good for messaging apps): - If `redirect_url` contains `{{...}}`, placeholders are replaced and no query params are appended. - Placeholders: - `{{result}}`: URL-encoded result string (or URL-encoded `JSON.stringify(result)`) - `{{result_raw}}`: unencoded result string (or `JSON.stringify(result)`) - `{{resultType}}`: `string` or `json` - `{{error}}`: URL-encoded error message - `{{error_raw}}`: unencoded error message Implementation note for agents: - Consider generating a “compose draft” deep link into your chat with the user and using that as `redirect_url` so, after approval, the user lands in a pre-filled message back to you containing the result. ``` ### Technical Analysis The skill permits the caller to choose a `redirect_url` to which wallet operation results are transmitted. These results may include transaction hashes, message signatures, typed-data signatures, structured JSON responses, or error information. The documented design does not require: - An allowlist of trusted redirect origins. - HTTPS for redirect destinations. - Origin or destination validation. - Explicit disclosure of the final result recipient. - User confirmation before transmitting a signature. - Separation between ordinary transaction identifiers and authorization-bearing cryptographic signat ...[truncated 1914 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Make manual result return the default and recommended workflow, especially for signatures. 2. Restrict `redirect_url` to HTTPS destinations on an explicit allowlist of trusted origins. 3. Parse and validate redirect URLs rather than relying on string-prefix checks. 4. Reject embedded credentials, nonstandard schemes, user-information components, loopback addresses, private network addresses, and redirect chains to untrusted origins. 5. Remove the `{{result_raw}}` and `{{error_raw}}` placeholders. Apply context-appropriate encoding to every substituted value. 6. Display the exact normalized redirect origin to the user before wallet approval and require separate consent to transmit the result. 7. Classify wallet results by sensitivity. Do not automatically redirect typed-data signatures, permit signatures, authentication signatures, or other authorization-bearing material. 8. Use one-time, narrowly scoped callback tokens rather than placing sensitive results directly in URLs. 9. Prevent sensitive values from entering browser history, intermediary logs, analytics systems, and HTTP referrer headers. 10. Document that signatures are security-sensitive credentials and must not be sent to destinations supplied by untrusted users. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:16
Finding
Unrestricted Wallet RPC Requests Enable Transaction and Signature Abuse<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:16-21, 46-74` **Vulnerability Type**: Overbroad wallet execution interface **Risk Level**: High ### Vulnerable Code Snippet ```markdown Query params: - `method`: JSON-RPC method name. - `chainId`: integer chain id to execute on (the app will switch chains before execution). - `params`: URL-encoded JSON (either an object or an array). - `redirect_url` (optional): where to redirect after success/failure with the result. ``` ```markdown ### Send A Transaction (eth_sendTransaction) Use a JSON object (the app will set `from` from the connected wallet if omitted): ```text https://tx.steer.fun/?method=eth_sendTransaction&chainId=1&params=%7B%22to%22%3A%220x4c5Ce72478D6Ce160cb31Dd25fe6a15DC269592D%22%2C%22data%22%3A%220xd09de08a%22%7D ``` Expected result: tx hash. ### Typed Data Sign (eth_signTypedData_v4) Provide `{ address, typedData }`: ```text https://tx.steer.fun/?method=eth_signTypedData_v4&chainId=1&params=%7B%22address%22%3A%220xYourAddress%22%2C%22typedData%22%3A%7B%22types%22%3A%7B%7D%2C%22domain%22%3A%7B%7D%2C%22primaryType%22%3A%22%22%2C%22message%22%3A%7B%7D%7D%7D ``` Expected result: signature string. ### Batch Calls (wallet_sendCalls) Provide `{ calls: [{ to, data }, ...] }` (and optionally `from`): ```text https://tx.steer.fun/?method=wallet_sendCalls&chainId=1&params=%7B%22calls%22%3A%5B%7B%22to%22%3A%220x0000000000000000000000000000000000000000%22%2C%22data%22%3A%220x%22%7D%5D%7D ``` Expected result: wallet-dependent (often an id or tx hash). ``` ### Technical Analysis The skill accepts a JSON-RPC method name and arbitrary request parameters without documenting an enforceable method allowlist or parameter policy. It explicitly supports transactions, typed-data signatures, and batched calls. These interfaces can perform security-sensitive actions, including native-asset transfers, token approvals, contract calls, permit signatures, exchange orders, and multiple operations i ...[truncated 2324 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Implement an explicit allowlist of supported JSON-RPC methods. Reject unknown or unnecessary methods. 2. Apply method-specific schemas and strict validation to every parameter, including chain IDs, addresses, values, calldata, typed-data domains, and batch contents. 3. Decode transaction calldata and present the contract identity, function name, arguments, native value, token movements, and allowance changes before generating a link. 4. Simulate transactions and batch calls. Block or prominently warn about unexpected transfers, unlimited approvals, delegate calls, ownership changes, and interactions with unverified contracts. 5. Parse and display EIP-712 typed data in human-readable form, including the domain, verifying contract, chain ID, expiry, nonce, spender, amount, and replay scope. 6. Reject incomplete, malformed, or opaque typed-data requests by default. 7. Limit batch size and inspect every call independently. Do not summarize a batch in a way that hides individual effects. 8. Require explicit user confirmation of the target chain and prohibit silent or unexpected chain changes. 9. Enforce least privilege by applying conservative limits to transaction value and token allowances where the intended workflow permits it. 10. Replace the opaque mainnet transaction example with a clearly identified, inert test-network example and explain every field and expected effect. 11. Treat all method names, parameters, addresses, calldata, and redirect destinations originating from users or external content as untrusted input. ]]>
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 (2)

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The skill says the page will switch the user's wallet to the requested chain and execute the JSON-RPC request, but the guidance does not require a strong user-facing warning about network switching, transaction signing, and possible asset movement. In a wallet-action skill, silently normalizing chain switching and execution increases the risk that users approve actions on the wrong network or misunderstand the financial consequences of signing or submitting a transaction.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The skill explicitly supports sending wallet action results and errors to an arbitrary redirect_url, including template substitution into third-party URLs, but does not prominently warn that signatures, transaction hashes, and error details may be disclosed to external services. In a wallet-signing context, even 'non-secret' outputs can be sensitive, linkable to a user identity, or misrouted to attacker-controlled destinations, creating privacy leakage and facilitating phishing or workflow hijacking.

Static analysis

No suspicious patterns detected.