The Trench

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:47 AM UTC
• Version: 0.1.0

Overview

This is a small Solana devnet client guide, but its sample can silently use whatever RPC endpoint and wallet are configured in the environment despite saying devnet.

Review the sample before use. If you install it, ensure the agent explicitly selects and displays the RPC endpoint, cluster, wallet public key, program ID, accounts, and expected transaction effects before any .rpc() call. Prefer constructing AnchorProvider with the declared devnet Connection instead of using AnchorProvider.env().

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 (1)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:19

Finding

Environment-Configured Provider Bypasses the Declared Devnet Connection

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 19–21
Vulnerability Type: Provider and network configuration mismatch
Risk Level: Medium

ts

const connection = new Connection("https://api.devnet.solana.com", "confirmed");
const provider = AnchorProvider.env();
const program = new Program(idl as any, programId, provider);

Technical Analysis

The example creates an explicit Solana devnet connection, but never passes it to the Anchor provider. Instead, AnchorProvider.env() obtains the RPC endpoint and wallet from ambient environment variables such as ANCHOR_PROVIDER_URL and ANCHOR_WALLET.

Therefore, the code does not enforce the Skill's stated devnet-only scope. The Program instance uses the environment-derived provider rather than the declared devnet connection. If those environment variables are stale, misconfigured, or attacker-controlled, operations can be routed through an unintended or malicious RPC endpoint and use an unintended local wallet. The example also lacks cluster identity verification and explicit confirmation of the selected wallet and network before transaction signing.

Attack Path

1. An attacker, compromised development environment, shell initialization file, or automation configuration changes ANCHOR_PROVIDER_URL or ANCHOR_WALLET.
2. The user follows the documented example under the assumption that the hardcoded devnet connection will be used.
3. AnchorProvider.env() loads the influenced RPC URL and wallet path.
4. The unused connection variable provides no protection or network enforcement.
5. Subsequent method calls query chain state or submit signed transactions through the unintended provider.
6. A malicious RPC service may return deceptive state or transaction data, collect transaction metadata, or interfere with transaction submission. If the selected wallet and referenced program are valid on another cluster, a transaction may also be submitted ...[truncated 678 chars]

Remediation

View remediation

Remediation Suggestions

• Construct the provider explicitly with the declared connection instead of using AnchorProvider.env():

  ts

  const connection = new Connection("https://api.devnet.solana.com", "confirmed");
  const wallet = /* explicitly selected and validated wallet */;
  const provider = new AnchorProvider(connection, wallet, {
    commitment: "confirmed",
  });
  const program = new Program(idl as any, programId, provider);
  

• Require deliberate wallet selection rather than silently accepting an ambient ANCHOR_WALLET value.
• Verify the RPC cluster identity, such as its genesis hash, before reading state or requesting a signature.
• Display the selected RPC endpoint, cluster, wallet public key, program ID, accounts, instruction data, and expected balance changes before signing.
• Require explicit user confirmation for every state-changing transaction.
• Validate that the loaded IDL declares the expected program address and obtain the IDL from a pinned, trusted project artifact.
• Package or otherwise make available the referenced idl.json and the_trench.ts files so that the complete client interface can be reviewed and integrity-checked.

SkillSpector

Vulnerability Patterns

• 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
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep