Security audit

solana-development

Security checks across malware telemetry and agentic risk

Overview

The skill is a coherent Solana development guide, but some examples and deployment commands could mislead users into risky real-chain actions or unsafe smart-contract patterns.

Install only if you want a Solana reference skill and are comfortable reviewing its examples critically. Do not treat copied snippets as production-ready, especially token transfer, compressed account, unsafe Rust, and mainnet deployment sections. Require explicit confirmation before any command that deploys, writes buffers, changes upgrade authority, closes programs, or uses mainnet funds.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access

Findings (12)

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The documentation incorrectly states that all accounts must be rent-exempt and that non-exempt accounts cannot be created. In a Solana development reference, this can mislead developers into making incorrect security and correctness assumptions about account lifecycle, validation, or program behavior, which may result in flawed program logic or missed edge cases.

Intent-Code Divergence

Medium

Confidence: 92% confidence
Finding: The 'Missing Signer Check' example describes an exploit path that is not valid as written because Solana programs cannot arbitrarily debit lamports from accounts they do not own. In security guidance, inaccurate exploit mechanics are dangerous because they teach developers the wrong threat model and can cause them to misunderstand what signer checks do and do not protect, potentially leading to real authorization flaws elsewhere.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The 'Read-Only Access' example is mislabeled: it constructs a mutable compressed account with `new_mut()` and then invokes the Light System Program with `with_light_account(account)?.invoke(...)`, which follows a consume-and-recreate write path. In compressed-account systems, even recreating the same logical state can mutate state commitments, consume proofs/nullifiers, or create concurrency and replay hazards, so developers copying this pattern may unintentionally perform writes in code they believe is read-only.

Intent-Code Divergence

Medium

Confidence: 92% confidence
Finding: The Anchor escrow example uses plain `transfer` while the document later recommends `transfer_checked` as the safer default. In documentation for smart-contract development, inconsistent examples are dangerous because readers frequently copy them directly, and unchecked transfers reduce mint/decimals validation at the CPI boundary, increasing the chance of account-confusion or wrong-mint integration mistakes if surrounding constraints are incomplete or later modified.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The native escrow example also demonstrates raw SPL `transfer` even though the same file later states `transfer_checked` should be used for security. Native Rust examples are especially risky because they lack Anchor's declarative constraints, so copied code may omit mint/decimals verification entirely and enable wrong-account or wrong-mint token handling bugs in derived implementations.

Intent-Code Divergence

Medium

Confidence: 93% confidence
Finding: The staking example conflicts with the document's own security guidance by transferring tokens with plain `transfer`. Because this is instructional material for Solana program authors, the skill context makes the issue more dangerous: developers may treat the sample as production-ready and inherit weaker transfer validation into staking vault logic, where mistakes can lock or misroute user funds.

Intent-Code Divergence

Medium

Confidence: 94% confidence
Finding: The unstaking example repeats the same unsafe pattern during withdrawal, using unchecked `transfer` from a vault PDA to the user token account. In a staking/vault pattern, outbound transfers are high-value operations; if developers copy this without strong surrounding account validation, they risk wrong-destination or mismatched-mint withdrawals and inconsistent security posture across the codebase.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The document provides mainnet deployment commands that trigger real, irreversible on-chain state changes and spend real SOL, but the warning is minimal and embedded after the fact rather than prominently framing the section as hazardous. In a developer skill that may be followed verbatim, this increases the risk of accidental production deployment, financial loss, and unintended exposure of unaudited programs.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The buffer upload workflow omits a strong warning that writing a program buffer creates a persistent on-chain artifact and incurs real network costs. Users may execute these commands assuming they are harmless preparation steps, leading to unintended spending, stale deployment artifacts, or governance confusion around upgrade buffers.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: Program close commands are destructive and can permanently remove deployment artifacts or reclaim rent from important program/buffer accounts, yet the section lacks a strong pre-execution safety warning. In a deployment reference, users may copy these commands without appreciating that they can disrupt operational programs, governance workflows, or incident recovery options.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The guidance demonstrates converting a user-controlled u8 into an enum using `unsafe { std::mem::transmute(...) }` after a manual range check. Even though the example checks `rarity_value > 4`, normalizing `unsafe` in a security reference is dangerous because future readers may copy the pattern without preserving the guard, and enum layout/validity assumptions are brittle compared to safe parsing approaches.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The guide acknowledges that hardware wallets cannot fully verify ALT-resolved accounts, but this warning appears later than the main construction and usage examples for v0 transactions. That ordering can lead developers to copy insecure patterns into production UX without realizing users may be signing transactions whose effective accounts are not fully inspectable, increasing phishing and account-substitution risk.

VirusTotal

VirusTotal findings are pending for this skill version.

View on VirusTotal

Static analysis

No suspicious patterns detected.