solana-token-distribution

• Outcome: Review
• Latest audit: Sep 11, 2026 · 12:18 AM UTC
• Version: 1.0.1

Overview

This is a coherent Solana token-distribution skill, but its examples include real mainnet signing and sending patterns with weak transaction safety guardrails.

Review and adapt the examples before using this skill with production wallets. Prefer devnet or localnet first, pin and verify the install source, keep RPC keys and payer keys in a secrets manager, enable preflight or simulation for batches, confirm recipients and total amounts, and avoid JavaScript number arithmetic for token quantities.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Findings (3)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:172
• Finding: Unpinned Executable Installation Creates Supply-Chain Risk<. ``` ### Technical Analysis The documented installation command invokes an `npx`-provided CLI and identifies the Skill repository by a mutable owner/repository reference. Neither the CLI package version nor the repository revision is pinned to a reviewed version or commit. Consequently, the content installed by this command can differ from the content originally audited. Compromise of the CLI package, its dependency chain, the upstream repository, or its maintainer account could introduce modified instructions or executable content into a subsequent installation. The audited project itself does not contain a malicious payload, and the command is documentation rather than an automatically executed installation hook. The risk arises when an operator follows the documented command without independently pinning and verifying the fetched components. ### Attack Path 1. An attacker compromises the package used by `npx`, one of its transitive dependencies, or the referenced upstream repository. 2. The attacker publishes a malicious package version or changes the repository content while retaining the same mutable package/repository name. 3. An operator follows the documented `npx skills add Lightprotocol/skills` command. 4. `npx` resolves the current package version, and the installer retrieves the current upstream Skill content. 5. The malicious installer or modified Skill content runs or is activated with the operator's permissions. ### Impact Assessment Successful exploitation could execute supply-chain code with the privileges of the user running the installation. Depending on that user's environment, this could expose local files, environment varia ...[truncated 266 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin the installation CLI to a reviewed version, for example by using an explicit package version rather than allowing `npx` to resolve the latest release. - Pin the Skill repository to an immutable commit hash or cryptographically signed release tag. - Publish and verify checksums or signatures for downloaded Skill content. - Use a lockfile and integrity-protected dependency installation where supported. - Download and inspect third-party content before enabling it in an Agent environment. - Run installation in a sandbox with no wallet key, RPC credential, or unrelated filesystem access. - Document the exact reviewed package version and repository commit in `SKILL.md`. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/batched-airdrop.md:196
• Finding: Transaction Preflight Is Disabled in the Batched Airdrop Example<![CDATA[ ## Vulnerability Details **File Location**: `references/batched-airdrop.md:196-203` **Vulnerability Type**: Unsafe financial transaction submission configuration **Risk Level**: Medium ### Vulnerable Code ```typescript const confirmedSig = await sendAndConfirmTx(connection, tx, { skipPreflight: true, commitment: "confirmed", }); if (confirmedSig) { statusMap[index] = 1; return { type: BatchResultType.Success, index, signature: confirmedSig }; } ``` ### Technical Analysis The production-oriented batched airdrop example submits signed transactions with `skipPreflight: true`. This suppresses the RPC simulation normally performed before transaction submission. Preflight does not replace application-level recipient and amount validation, but it can detect malformed instructions, account-state conflicts, insufficient balances, compute-limit failures, and other deterministic execution errors before broadcasting. Disabling it is particularly risky in a large batch operation because the example concurrently sends batches and retries failed submissions. The retry implementation marks successful confirmations and does not intentionally resend confirmed batches. Nevertheless, suppressing simulation reduces the opportunity to identify invalid configuration before fees are incurred and complicates diagnosis of systemic batch failures. ### Attack Path 1. Invalid recipient data, incorrect account configuration, stale state, an unsuitable lookup table, or malformed batch parameters enter the transaction-building process. 2. The payer signs the resulting transaction. 3. Because `skipPreflight` is enabled, the RPC endpoint does not simulate and reject the known-invalid transaction before submission. 4. The transaction is broadcast and may fail during on-chain processing. 5. The retry loop signs and submits additional attempts until the retry limit is reached, potentially incurring repeated fees and operational disruption across multiple batches. An at ...[truncated 871 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Make `skipPreflight: false` the default for documented production workflows. - Simulate every batch before signing or broadcasting it and reject batches that return an execution error. - Permit bypassing preflight only through an explicit, prominently documented operator option. - Validate recipient addresses, mint, source account, token balance, amount bounds, lookup-table availability, and network selection before building transactions. - Perform a dry run on devnet or localnet before a large mainnet distribution. - Stop the overall operation when repeated batches fail for the same deterministic reason instead of retrying every batch independently. - Record batch identifiers, intended recipients, amounts, signatures, and final confirmation states to support safe reconciliation and restart. - Distinguish transient RPC or blockhash errors from deterministic program errors and retry only transient failures. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/batched-airdrop.md:249
• Finding: Token Supply Uses an Unsafe JavaScript Number Representation<![CDATA[ ## Vulnerability Details **File Location**: `references/batched-airdrop.md:249-254` **Vulnerability Type**: Unsafe numeric handling for token quantities **Risk Level**: Medium ### Vulnerable Code ```typescript const ata = await getOrCreateAssociatedTokenAccount( connection, PAYER, mint, PAYER.publicKey ); await mintTo(connection, PAYER, mint, ata.address, PAYER.publicKey, 10e9 * 1e9); ``` ### Technical Analysis The mint quantity is constructed as a JavaScript `number`: ```typescript 10e9 * 1e9 ``` The result is `10,000,000,000,000,000,000`, which exceeds JavaScript's `Number.MAX_SAFE_INTEGER`. Although this particular decimal value may be representable, JavaScript no longer guarantees exact representation of arbitrary neighboring integer quantities at this magnitude. Small edits to the example or values derived from user input can therefore be rounded before they reach the token library. Token quantities are integer financial values and should be represented using `bigint` or a validated arbitrary-precision integer type. Using floating-point arithmetic can also cause an SDK to reject the amount if it enforces safe-integer constraints, resulting in an unexpected failure rather than a successful mint. ### Attack Path 1. An operator copies the example and changes the intended token supply, decimal count, or multiplier. 2. The resulting quantity remains above `Number.MAX_SAFE_INTEGER` but is not exactly representable as a JavaScript `number`. 3. JavaScript rounds the value before it is passed to `mintTo`, or the SDK rejects the unsafe numeric input. 4. If accepted, the payer signs a transaction containing a quantity different from the intended value; if rejected, the minting workflow fails. 5. Subsequent airdrop calculations may be based on an incorrect or unavailable supply. If an external party can influence the numeric supply calculation, that party could choose a value that loses precision. The provided example uses a fixed expression and ...[truncated 717 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Represent token quantities as `bigint` throughout the workflow: ```typescript const wholeTokens = 10_000_000_000n; const baseUnitsPerToken = 1_000_000_000n; const supply = wholeTokens * baseUnitsPerToken; await mintTo( connection, PAYER, mint, ata.address, PAYER.publicKey, supply ); ``` - Parse user-provided quantities from decimal strings rather than converting them through JavaScript `number`. - Reject fractional, negative, out-of-range, or malformed quantities before transaction construction. - Validate the amount against the mint's decimal configuration and applicable token-supply limits. - Display the exact base-unit quantity and require operator confirmation before signing a production mint transaction. - Add tests for values at and above `Number.MAX_SAFE_INTEGER`, including quantities that cannot be represented exactly as JavaScript numbers. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (4)

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 91% confidence
• Finding: The skill instructs users to install from `npx skills add Lightprotocol/skills` without pinning a specific package or revision. This creates a supply-chain risk: a future compromised or maliciously updated package/version could be fetched and executed at install time, and `npx` commonly runs remote package code directly.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The example is configured for mainnet, creates a mint, mints supply, and submits batched transactions using a real RPC endpoint, but it does not prominently warn that running it will create and move real on-chain assets and incur real fees. In a token-distribution skill, users are likely to copy-paste examples directly, so omission of environment safety guidance materially increases the risk of accidental mainnet execution and unintended asset issuance or fee spend.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: This example constructs and submits a real token distribution transaction to multiple recipients, but it does not clearly warn users that running it will move actual assets if valid keys, mint addresses, and recipients are supplied. In a blockchain context, copy-pasting sample code without explicit safety warnings can lead to unintended transfers, especially because the example includes transaction signing and broadcasting logic.

Missing User Warnings

Low

• Confidence: 84% confidence
• Finding: The markdown demonstrates pulling an RPC API key from an environment variable but gives no handling guidance about protecting credentials, avoiding accidental logging, or scoping the key to intended environments. While this alone is not credential exfiltration, documentation that normalizes direct use of production API keys without warnings can lead to leakage through shell history, screenshots, shared scripts, or misconfigured CI environments.

Static analysis

No suspicious patterns detected.