Common Vulnerabilities in Solana Programs

Overview

Through our extensive audit work across hundreds of Solana programs, we have identified recurring vulnerability patterns that appear with alarming frequency. Understanding these common pitfalls is essential for developers aiming to write secure on-chain code, whether using native Rust or the Anchor framework.

Missing Owner and Signer Checks

The single most common vulnerability class remains insufficient account validation. Every account passed into a Solana instruction must be verified: Is it owned by the expected program? Is the required signer present? Does the account's data match the expected discriminator? Omitting any of these checks can allow an attacker to substitute a malicious account, potentially draining funds or corrupting state. Anchor's Account type handles much of this automatically, but custom deserialization logic and remaining accounts still require manual validation.

Arithmetic Overflows and Precision Loss

Despite Rust's safety guarantees, integer overflows remain a real threat in Solana programs. When computing token amounts, fee calculations, or share conversions, developers frequently use unchecked arithmetic or lose precision through truncating division. An attacker who can manipulate inputs to trigger an overflow or rounding error may be able to mint excess tokens, withdraw more than their fair share, or bypass fee mechanisms. Always use checked_add, checked_mul, and checked_div, and consider the order of operations to maximize precision.

Cross-Program Invocation Risks

Solana's composability through CPI is powerful but introduces trust boundary concerns. When your program invokes another, you must ensure that the target program ID is the one you expect — not an attacker-controlled program with the same interface. Similarly, the accounts passed through CPI calls should be re-validated, as a malicious caller could craft an outer instruction that passes legitimate-looking but ultimately hostile accounts. PDA (Program Derived Address) seeds must be constructed deterministically and checked for uniqueness to prevent seed collision attacks.

Building a Security-First Culture

Eliminating these vulnerabilities requires more than static analysis tools, though tools like our X-ray scanner are a valuable first line of defense. Teams should adopt a security-first development culture: threat-model new features before writing code, write invariant tests that attempt to break assumptions, and engage external auditors who specialize in Solana's unique execution model. The cost of prevention is always less than the cost of an exploit.