Back to skill

Security audit

TRON

Security checks for vulnerabilities and agentic risk

Overview

This is a documentation-only TRON guidance skill with no executable behavior, though it contains one financially relevant resource-cost claim users should verify before acting on.

Installers should treat this as a lightweight TRON reference skill, not an authoritative transaction-safety source. Before sending or retrying TRX, TRC-20, or smart-contract transactions, verify current bandwidth, energy, fee limits, and failure receipts with current TRON wallet or explorer data.

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:59
Finding

Misleading Guidance About Resource Consumption by Failed TRON Transactions

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 13 and 59
Vulnerability Type: Insecure and financially unsafe transaction guidance
Risk Level: Medium

Affected content:

markdown
- Transactions fail without sufficient resources — no partial execution
markdown
- Failed transactions don't consume resources — unlike Ethereum gas

Technical Analysis

The unconditional statement that failed TRON transactions do not consume resources is inaccurate. A failed or reverted smart-contract transaction can consume bandwidth and energy for work performed before failure. Depending on the account's available resources and transaction configuration, the corresponding cost may be paid by burning TRX.

Atomic rollback of contract state does not imply that transaction execution is free. The statement at line 13 may reinforce this misunderstanding by discussing failure without distinguishing reverted state changes from resource accounting.

Because the skill provides financial transaction guidance, an agent relying on these instructions may incorrectly assure users that failed TRC-20 transfers or decentralized-application interactions have no resource or monetary cost.

Attack Path

  1. A user asks the agent for guidance about a TRC-20 transfer or smart-contract interaction.
  2. The agent loads SKILL.md and relies on the claim that failed transactions consume no resources.
  3. The user submits a transaction that reverts, runs out of energy, or otherwise fails during contract execution.
  4. Bandwidth or energy is consumed, and TRX may be burned when the account lacks sufficient allocated resources.
  5. Based on the incorrect assurance, the user may retry the transaction repeatedly and incur additional costs.

This is primarily a transaction-safety failure rather than a privilege-escalation vulnerability. It does not provide an attacker with system privileges, wallet credentials, or direct account a ...[truncated 715 chars]

Remediation
View remediation

Remediation Suggestions

Replace the unconditional claims with technically accurate guidance that distinguishes state rollback from resource charging. For example:

markdown
- Transactions can fail when resources or fee limits are insufficient. Contract state changes normally revert, but bandwidth and energy consumed during execution may still be charged.
- Failed smart-contract transactions may consume bandwidth and energy, and TRX may be burned when allocated resources are insufficient. Review the execution result and resource usage before retrying.

Additional hardening measures:

  1. Clearly distinguish simple TRX transfers from smart-contract and TRC-20 transactions.
  2. Avoid absolute statements about fees or resource consumption because behavior can depend on transaction type, failure mode, fee limits, and current network rules.
  3. Advise users to estimate energy, inspect available resources, and configure an appropriate fee limit before signing.
  4. Warn users not to retry a failed transaction until they have reviewed its receipt, contract error, and recorded resource consumption.
  5. Periodically validate numerical and behavioral claims against current official TRON documentation.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • 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

Static analysis

No suspicious patterns detected.