RUST001 |
Unsafe code block |
High |
Unsafe code blocks can lead to undefined behavior if not used properly. |
Ensure that unsafe code is necessary and properly reviewed. Use safe abstractions when possible. |
RUST002 |
Unhandled error |
Medium |
Unwrapping a Result or Option without proper error handling can lead to panic. |
Use match or if let to handle the Result or Option properly, or use ? to propagate the error. |
RUST003 |
Unchecked arithmetic |
Medium |
Arithmetic operations that can overflow or underflow without being checked. |
Use checked arithmetic methods like checked_add , checked_sub , checked_mul , and checked_div . |
RUST004 |
Insecure random number generator |
High |
Using an insecure random number generator for security-sensitive operations. |
Use a cryptographically secure random number generator like rand::ThreadRng or ring::rand::SystemRandom . |
RUST005 |
Uninitialized memory |
High |
Using uninitialized memory can lead to undefined behavior. |
Initialize memory properly or use mem::MaybeUninit for delayed initialization. |
RUST006 |
Use of mem::transmute |
High |
Using mem::transmute can lead to undefined behavior and violate type safety. |
Avoid using mem::transmute and use safe type conversions or as keyword for primitive types. |
RUST007 |
Use of std::process::Command |
Medium |
Using std::process::Command without properly sanitizing user input can lead to command injection vulnerabilities. |
Properly sanitize and validate user input before passing it to std::process::Command . Consider using safe wrappers or libraries. |
RUST008 |
Use of std::fs::File with unwrap() |
Medium |
Using unwrap() with std::fs::File can lead to panics if the file operation fails. |
Use ? operator to propagate the error or handle it explicitly with match or if let. |
RUST009 |
Deserialization of untrusted data |
High |
Deserializing untrusted data without proper validation can lead to security vulnerabilities. |
Implement custom deserialization logic with proper validation and sanitization of untrusted data. Consider using safe deserialization libraries. |
RUST010 |
Use of std::net::TcpListener with unwrap() |
Medium |
Using unwrap() with std::net::TcpListener can lead to panics if the binding operation fails. |
Use ? operator to propagate the error or handle it explicitly with match or if let. |
VULN001 |
Integer Overflow or Underflow |
High |
Performing arithmetic operation without checking for overflow or underflow. |
Use checked_add , checked_sub , checked_mul , or checked_div to safely perform arithmetic operations. |
VULN002 |
Loss of Precision |
High |
The use of try_round_u64() for rounding up may lead to loss of precision. |
Use try_floor_u64() to prevent potential loss of precision. |
VULN003 |
Inaccurate Calculation Results |
High |
Reliance on saturating arithmetic operations without considering precision loss. |
Consider using checked_add , checked_sub , checked_mul , or checked_div to handle arithmetic operations explicitly and avoid precision loss. |
VULN007 |
Missing Check for the Permission of Caller |
Low |
Missing verification of caller permissions before sensitive operations. |
Implement and invoke a permission check function to verify the caller's authority. |
VULN008 |
Account Signer Check |
High |
Ensure the expected signer account has actually signed to prevent unauthorized account modifications. |
Verify is_signer is true for transactions requiring signatures. |
VULN009 |
Account Writable Check |
High |
Ensure state accounts are checked as writable to prevent unauthorized modifications. |
Verify is_writable is true for accounts that should be modified. |
VULN010 |
Account Owner or Program ID Check |
High |
Verify the owner of state accounts to prevent fake data injection by malicious programs. |
Check the account's owner matches the expected program ID. |
VULN011 |
Account Initialized Check |
High |
Prevent re-initialization of already initialized accounts. |
Ensure account's is_initialized flag is checked before initializing. |
VULN017 |
Signer Authorization - Anchor |
High |
Signer check is missing, which could lead to unauthorized execution. |
Add a check to verify if the caller is a signer. |
VULN018 |
Account Data Matching - Anchor |
High |
Missing verification of token ownership or mint authority in SPL Token accounts. |
Verify token ownership matches the expected authority before proceeding. |
VULN019 |
Owner Checks - Anchor |
High |
Missing checks on the owner field in the metadata of an Account or on the Account itself. |
Ensure the owner of the account is verified against the expected program ID. |
VULN020 |
Type Cosplay - Anchor |
High |
Risks of different accounts impersonating each other by sharing identical data structures. |
Add discriminant checks to differentiate account types securely. |
VULN021 |
Check Initialize - Anchor |
High |
Data should only be initialized once; missing checks can lead to reinitialization. |
Use a flag to ensure data is initialized only once. |
VULN022 |
Arbitrary CPI - Anchor |
High |
Unverified target program id in CPI can lead to arbitrary code execution. |
Ensure the target program id is verified against expected program id. |
VULN023 |
Duplicate Mutable Accounts - Anchor |
High |
Passing the same mutable account multiple times may result in unintended data overwriting. |
Add checks to ensure that mutable accounts passed are distinct. |
VULN024 |
Bump Seed Canonicalization - Anchor |
High |
Improper validation of bump seeds can lead to security vulnerabilities. |
Use find_program_address for bump seed canonicalization and validate against expected seeds. |
VULN025 |
PDA Sharing - Anchor |
High |
Sharing PDA across multiple roles without proper permission separation may lead to unauthorized access. |
Ensure PDAs used across roles have distinct seeds and permissions. |
VULN026 |
Closing Accounts - Anchor |
High |
Improper closing of accounts may leave them vulnerable to misuse. |
Ensure accounts are properly closed by transferring lamports and marking with a discriminator. |
VULN027 |
Sysvar System Account Not Checked |
High |
Sysvar system account is accessed without verifying its legitimacy, exposing the contract to potential manipulation or attacks. |
Before deserializing information from a sysvar account, verify that the incoming address matches the expected sysvar ID. |
VULN028 |
PDA Account Misuse Without Proper Verification |
High |
The PDA account is utilized without validating the caller's and beneficiary's accounts, allowing unauthorized actions. |
Implement checks to verify the depositor's signature and ensure the deposit_account cannot be forged. |
VULN029 |
Unchecked Account Deserialization |
High |
Failing to check if an account is of the expected type before deserializing can lead to incorrect assumptions about state. |
Ensure accounts are of the expected type before deserialization. |
VULN031 |
CPI to Unauthorized Programs |
High |
Invoking unauthorized or risky external programs can expose the contract to vulnerabilities present in those programs. |
Whitelist external programs that can be invoked, and perform thorough security reviews on them. |
Rust-Solana001 |
Misuse of Unsafe Code |
High |
Unsafe blocks may lead to undefined behavior and memory safety violations if not used carefully. |
Minimize the use of unsafe by leveraging safe Rust-Solana abstractions and validate all unsafe blocks for safety guarantees. |
Rust-Solana002 |
Improper Error Handling |
Medium |
Overuse of unwrap() or expect() can lead to panics. |
Prefer using error handling mechanisms like match or if let. Replace unwrap() and expect() with proper error handling to prevent unexpected panics in production code. |
Rust-Solana003 |
Overuse of Panics for Control Flow |
Medium |
Using panics for control flow makes code hard to follow and can lead to unexpected termination. |
Use Result types for error handling and reserve panics for unrecoverable errors only. |
Rust-Solana004 |
Concurrency Issues and Data Races |
High |
Improper handling of threads and synchronization can lead to data races, deadlocks, and other concurrency issues. |
Use Rust-Solana's concurrency primitives correctly, prefer std::sync module's types like Mutex, RwLock, and leverage the rayon crate for data parallelism. |
Rust-Solana005 |
Potential Memory Leaks |
Low |
Cyclic references or improper use of smart pointers can lead to memory leaks. |
Use Weak pointers to break cycles and audit memory usage regularly. |
Rust-Solana006 |
Potential DoS Vulnerabilities |
High |
Allocations based on untrusted input sizes can lead to DoS via memory exhaustion. |
Validate input sizes before allocations and use bounded collections. Consider rate-limiting or other mitigation strategies. |
Rust-Solana007 |
Missing Boundary Checks |
Medium |
Accessing arrays or vectors without boundary checks can lead to panics or buffer overflows. |
Use .get() or .get_mut() for safe access with bounds checking, and handle the Option result appropriately. |
Rust-Solana008 |
Unnecessary Cloning of Large Data Structures |
Low |
Cloning large data structures can lead to performance issues due to excessive memory use. |
Prefer borrowing or using reference-counted types like Rc or Arc to share data without deep copying. |
Rust-Solana009 |
Blocking I/O in Asynchronous Code |
Medium |
Performing blocking I/O operations in async contexts can lead to thread starvation and reduced scalability. |
Use asynchronous equivalents for file and network operations within async functions. |
Rust-Solana010 |
Misuse of Arc<Mutex> |
Medium |
Incorrect use of Arc<Mutex> can lead to deadlocks or inefficient locking mechanisms. |
Ensure that locks are held for the minimum duration necessary, and consider other synchronization primitives like RwLock if applicable. |
Rust-Solana011 |
Improper Implementation of Drop Trait |
Medium |
Incorrect custom implementations of the Drop trait can lead to resource leaks or panic safety issues. |
Implement the Drop trait carefully, ensuring that errors are handled gracefully and resources are properly released. |
Rust-Solana012 |
Usage of mem::uninitialized and mem::zeroed |
High |
Using mem::uninitialized or mem::zeroed can lead to undefined behavior if the type has any non-zero or complex initialization requirements. |
Prefer using safe initialization patterns and avoid these functions for types with non-trivial initialization requirements. |