tron-x402-payment-demo

• Outcome: Review
• Latest audit: Sep 10, 2026 · 10:37 AM UTC
• Version: 1.0.3

Overview

This payment demo is coherent in purpose, but it asks an agent to automatically sign TRON payment operations with a private key over a plaintext HTTP flow without clear per-transaction approval or limits.

Review this skill carefully before installing. Use only a dedicated low-balance demo wallet, do not provide a general-purpose TRON private key, and require manual verification of network, recipient, asset, amount, fees, and permit scope before any signature or payment is submitted.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:17

Finding

Payment Negotiation Uses an Unauthenticated Plaintext HTTP Endpoint

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, line 17
Vulnerability Type: Plaintext transport for security-sensitive payment negotiation
Risk Level: High

Vulnerable Code

markdown

1.  **Request Resource**: When triggered, follow the instructions provided by the `x402_payment_tron` skill to fetch the protected resource at `http://x402-tron-demo.sunagent.ai/protected`.

Technical Analysis

The skill directs the agent to negotiate access to a protected resource through plaintext HTTP. Because HTTP provides neither server authentication nor transport integrity, an on-path attacker could intercept and modify the response, including an HTTP 402 response and its associated payment parameters.

This is particularly security-sensitive because the next workflow step instructs the agent to sign and perform the requested payment automatically. Unless the referenced payment implementation independently authenticates every payment request, maliciously altered parameters could be treated as legitimate.

The implementation of the referenced x402_payment_tron skill is not included in the audited project, so the presence of compensating cryptographic validation cannot be verified.

Attack Path

1. A user invokes the x402 payment demo.
2. The agent requests the configured resource through plaintext HTTP.
3. An attacker with network-path control intercepts the request or response.
4. The attacker returns or modifies an HTTP 402 response containing attacker-selected payment parameters.
5. The agent passes those parameters to the automatic payment workflow.
6. If no independent recipient, amount, asset, network, and signature validation occurs, the agent signs and submits the manipulated transaction.
7. The attacker receives funds or substitutes the protected content.

Impact Assessment

A successful attack could redirect a payment, alter its amount or asset, substitute returned content, and reveal ...[truncated 304 chars]

Remediation

View remediation

Remediation Suggestions

• Replace the endpoint with an HTTPS URL and require valid certificate verification.
• Reject HTTPS-to-HTTP downgrade redirects and cross-origin redirects.
• Cryptographically authenticate payment requests independently of transport security.
• Validate the TRON network, chain identifier, recipient address, asset, amount, expiration time, nonce, and expected resource before signing.
• Pin or allowlist the expected payment origin and recipient where operationally feasible.
• Abort the workflow if any payment parameter differs from the approved demo configuration.
• Log non-secret transaction details so users can verify the payment and investigate anomalies.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:5

Finding

Private-Key-Backed Cryptocurrency Payment Is Performed Without Explicit Transaction Approval or Documented Limits

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 5–18
Vulnerability Type: Unbounded automatic cryptocurrency transaction signing
Risk Level: High

Vulnerable Code

yaml

metadata: {"clawdbot":{"emoji":"🖼️","env":["TRON_PRIVATE_KEY"],"triggers":["演示x402-payment", "demo x402-payment", "show me x402 demo"]}}

markdown

2.  **Handle Payment**: Perform the payment and resource acquisition automatically as guided by the protocol (handling 402 Payment Required, signing permits, etc.).

Technical Analysis

The skill declares access to a TRON_PRIVATE_KEY environment variable and instructs the agent to perform payment and permit-signing operations automatically. The documented workflow does not require transaction-specific user confirmation and does not define a maximum amount, approved recipient, approved token, expected network, fee ceiling, or transaction simulation requirement.

Although the file does not directly print or transmit the private key, it authorizes a workflow that can use the key for signing. Signing arbitrary or insufficiently validated permits can be dangerous because a signed authorization may grant token-spending rights beyond the immediate resource purchase.

The actual signing logic resides in the referenced x402_payment_tron skill, which was not present in the project. Therefore, this finding concerns the unsafe behavior required by the available instructions; it does not assert that the private key is directly exposed by executable code.

Attack Path

1. A user triggers the demo using one of the configured phrases.
2. The remote service supplies payment or permit parameters.
3. The agent processes those parameters automatically using the private-key-backed payment skill.
4. No transaction-specific confirmation is required by the documented workflow.
5. A malicious or compromised service supplies an excessive amount, attacker-controlled recipient, unexpected ...[truncated 692 chars]

Remediation

View remediation

Remediation Suggestions

• Require explicit user confirmation immediately before every signature.
• Present the exact network, recipient, asset, amount, fees, permit scope, expiration, and transaction identifier to the user.
• Enforce a hard-coded low spending ceiling suitable for a demonstration.
• Use a dedicated, low-balance demo wallet rather than a general-purpose wallet.
• Allowlist expected recipient addresses, contract addresses, token identifiers, and chain identifiers.
• Reject unlimited token allowances and permits that outlive the immediate transaction.
• Simulate the transaction and verify its decoded effects before signing.
• Separate key custody from the skill and expose only a narrowly scoped signing interface.
• Ensure the signing component never returns, logs, displays, or transmits the raw private key.
• Provide a dry-run mode that demonstrates the protocol without transferring real assets.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (1)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The skill instructs the agent to automatically perform an x402 payment on the TRON network and the metadata explicitly declares access to a blockchain private key via TRON_PRIVATE_KEY, but the user-facing description does not clearly warn that invoking the demo can spend funds. This creates a consent and authorization risk: a user may trigger what appears to be a harmless image demo while the agent signs blockchain payment operations on their behalf.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.