Back to skill

Security audit

W3connect

Security checks for vulnerabilities and agentic risk

Overview

This skill is openly for blockchain payments, but it gives agents a thinly scoped way to trigger real fund transfers using sensitive codes in URLs without clear confirmation safeguards.

Install only if you trust the local wallet service and will require manual review before every payment. Do not let an agent send funds unless you personally verify the destination address or email, token, chain, amount, and fees, and avoid exposing authenticator codes in command lines or shared logs.

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
SEND.md:20
Finding

Authenticator Code Exposed in URL for State-Changing Asset Transfer

Content
View full analysis

Vulnerability Details

File Location: SEND.md:20-22
Vulnerability Type: Sensitive authorization data in a state-changing HTTP GET request
Risk Level: High

Vulnerable Code:

bash
curl http://127.0.0.1:5333/send?code=[code]&chain=[chain]&to_address=[to_address]&token=[token]&amount=[amount]

Technical Analysis

The documented endpoint authorizes and initiates an ETH or USDC transfer through an HTTP GET request. Its six-digit authenticator code is placed directly in the URL query string alongside the transfer recipient and amount.

Query strings can be exposed through shell history, process command-line inspection, terminal or agent transcripts, debugging output, and HTTP access logs. Although the endpoint is bound to loopback, other local processes or users with sufficient process visibility may observe the URL. Plain HTTP also provides no application-layer transport protection, though loopback binding limits network exposure.

GET requests should be safe and idempotent, but this endpoint causes an irreversible financial operation. Using GET increases the possibility of unintended invocation by automated tooling, retries, URL handling, or prefetch behavior. The documentation states that the code remains valid for five minutes and can be used once, leaving a limited but material exploitation window.

Attack Path

  1. A legitimate user provides an authenticator code and requests an ETH or USDC transfer.
  2. The agent executes the documented curl command, placing the code and transaction parameters in the process command line and potentially in logs or transcripts.
  3. A local process, local user with process visibility, monitoring component, or party with access to generated logs captures the URL before the code expires.
  4. The attacker submits a request to the loopback service using the exposed authorization code, potentially replacing the recipient, token, or amount if the code is no ...[truncated 807 chars]
Remediation
View remediation

Remediation Suggestions

  • Replace the state-changing GET endpoint with an authenticated POST endpoint.
  • Transmit the authenticator code and transaction data in the request body rather than the URL.
  • Prefer a permission-restricted Unix-domain socket for local IPC. If HTTP is required, use authenticated TLS even for deployments where loopback exposure assumptions may change.
  • Cryptographically bind each authorization to the exact chain, token, recipient address, amount, nonce, and short expiry. Reject any request whose transaction details differ from those approved by the user.
  • Require explicit user confirmation that clearly displays the normalized recipient, token, chain, amount, and estimated fees before submission.
  • Redact authenticator codes and other authorization material from process output, application logs, agent transcripts, telemetry, and error messages.
  • Add Cache-Control: no-store and reject GET requests for all state-changing operations.
  • Enforce strict single-use semantics, rate limiting, short expiration, replay protection, transaction limits, and audit logging that omits secrets.
  • Pass request bodies through standard input or a protected temporary descriptor so secrets do not appear in command-line arguments.

T09 · Insecure Skill Coding Practices

Error
Location
PAY_TO_EMAIL.md:19
Finding

Authenticator Code and Recipient Email Exposed in Payment URL

Content
View full analysis

Vulnerability Details

File Location: PAY_TO_EMAIL.md:19-21
Vulnerability Type: Sensitive authorization data and personal information in a state-changing HTTP GET request
Risk Level: High

Vulnerable Code:

bash
curl http://127.0.0.1:5333/pay2email?code=[code]&chain=[chain]&token=[token]&amount=[amount]&to_email=[to_email]

Technical Analysis

The payment endpoint deposits USDC on-chain and initiates a payment to an email recipient using an HTTP GET request. The URL contains a six-digit authenticator code, the payment amount, and the recipient's email address.

URL query parameters commonly propagate into process listings, shell history, terminal or agent transcripts, proxy and application logs, debugging systems, and telemetry. This exposes both reusable authorization material during its stated five-minute lifetime and personally identifiable recipient information. Loopback binding reduces direct remote exposure but does not prevent disclosure to local processes or parties that can access collected logs.

The endpoint also violates HTTP method semantics by using GET for an operation that transfers funds and triggers an associated API call. Accidental requests, retries, or URL-processing behavior may therefore have financial side effects. Single-use enforcement reduces replay risk after successful consumption but does not protect against an attacker using a captured code first.

Attack Path

  1. A user supplies an authenticator code, USDC amount, and recipient email address.
  2. The agent invokes the documented command, exposing these values in the curl process arguments and potentially in logs or transcripts.
  3. An attacker with local process visibility or access to relevant logs captures the request while the code remains valid.
  4. The attacker invokes the loopback endpoint before the legitimate request consumes the code, potentially altering the amount or recipient email if auth ...[truncated 746 chars]
Remediation
View remediation

Remediation Suggestions

  • Replace the GET operation with an authenticated POST endpoint and place the code, amount, and recipient email in the request body.
  • Use a permission-restricted Unix-domain socket for local communication or authenticated TLS where HTTP is necessary.
  • Bind authorization to the normalized recipient email, chain, token, exact amount, nonce, and expiration so captured codes cannot authorize modified payment details.
  • Require explicit user confirmation of the recipient email and amount immediately before the transaction.
  • Redact authenticator codes, email addresses, and payment details from logs, telemetry, exception messages, command output, and agent transcripts.
  • Avoid command-line arguments for sensitive request bodies; provide data through standard input or another protected IPC mechanism.
  • Implement strict single-use enforcement, replay prevention, rate limiting, short expiration, payment limits, and anomaly detection.
  • Reject state-changing GET requests and return 405 Method Not Allowed.
  • Set Cache-Control: no-store and ensure all downstream PUSDC API calls follow equivalent secret-handling and data-minimization controls.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (5)

Missing User Warnings

High
Category
Not specified by scanner
Confidence
98% confidence
Finding

This documentation describes a tool that can initiate real on-chain transfers of ETH or USDC but does not warn users that blockchain transactions are irreversible, may transfer real funds, and cannot be undone if the address, amount, or chain is wrong. In an agent skill context, the absence of explicit safety guidance materially increases the risk of accidental or socially engineered fund loss because the skill normalizes direct transfer execution through a simple one-liner API call.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill handles both payment data and personal data (email address) and instructs users to send them to an API, but it provides no warning about the sensitivity of that transmission or the privacy implications. This can lead users or downstream agents to disclose financial and personal information without informed consent, especially since the endpoint and transport security expectations are not documented.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

The documented curl invocation directly triggers an on-chain deposit of funds, but the skill does not clearly warn that calling the endpoint has immediate financial consequences. In an agent-driven environment, this omission increases the risk of accidental execution, unintended transfers, or social-engineering prompts that cause users or tools to initiate real fund movement without adequate confirmation.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill description and invocation guidance are too sparse to define clear activation boundaries, while the skill itself concerns blockchain assets and transaction signing. In this context, vague routing criteria can cause the agent to invoke a financially sensitive skill in ambiguous situations, increasing the chance of unintended wallet operations or user confusion.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
95% confidence
Finding

The instruction 'Please do not ask the user to execute the curl for the agent' encourages the agent to act autonomously rather than keeping the user in the loop. Because this skill handles blockchain addresses, transfers, and transaction signatures, reducing user participation and confirmation creates a significant risk of unauthorized or unintended financial actions.

Content

Scanner excerpt · SKILL.md (reported line 12)May include surrounding context.

md
Use w3connect skill to execute.

Please do not ask the user to execute the curl for the agent.

  - GET_ADDRESS.md follow to check the how to get the address.

Static analysis

No suspicious patterns detected.