Full Report
In Anchor, the main framework for developing Solana programs, there are two identifiers for creating accounts: init and init_if_needed. init requires for account creation to occur otherwise it exists. init_if_needed will always run but will create the account if it doesn't already exist. So, is there anything an attacker can open where init is required? Associated Token Accounts (ATAs) are 100% permissionless to create. So, using init with ATAs is a bad idea.
Analysis Summary
# Vulnerability: Associated Token Account (ATA) Initialization Griefing
## CVE Details
- **CVE ID:** N/A (Design pattern flaw in Anchor-based Solana programs)
- **CVSS Score:** 5.3 (Medium)
- **CWE:** CWE-730: Total Denial of Service, CWE-404: Improper Resource Shutdown or Obstruction
## Affected Systems
- **Products:** Solana programs built using the Anchor Framework.
- **Versions:** All versions using Anchor's `#[account(init)]` macro for Associated Token Accounts.
- **Configurations:** Programs that facilitate the creation of Associated Token Accounts (ATAs) via instructions using the `init` constraint.
## Vulnerability Description
In Solana's Anchor framework, the `init` constraint is used to create and initialize a new account. When applied to an Associated Token Account (ATA), Anchor generates a Cross-Program Invocation (CPI) to the Associated Token Program's `Create` instruction (non-idempotent).
Because ATAs are 100% permissionless, an attacker can monitor the network and pre-create the ATA for a target user before the legitimate transaction is processed. When the program attempts to execute the `init` instruction, the validation logic checks if the account is currently owned by the `System Program`. Since the attacker has already initialized the account (changing its owner to the `Token Program`), the condition fails, and the instruction reverts. This allows a third party to "grief" users by blocking specific code paths.
## Exploitation
- **Status:** PoC available (Conceptual/Logically verified)
- **Complexity:** Low
- **Attack Vector:** Network (Permissionless creation of ATAs)
## Impact
- **Confidentiality:** None
- **Integrity:** None
- **Availability:** Medium (Enables Denial-of-Service (DoS) on specific instruction paths requiring ATA creation).
## Remediation
### Patches
There is no "patch" as this is a behavior of the `init` macro; however, Anchor provides alternative constraints.
### Workarounds
- **Use `init_if_needed`:** Replace `#[account(init, ...)]` with `#[account(init_if_needed, ...)]`. This constraint checks if the account is already initialized; if it is, Anchor skips the creation CPI and continues execution.
- **Manual Idempotent CPI:** Manually CPI into the Associated Token Program using the `CreateIdempotent` instruction instead of relying on the default `init` macro logic. This ensures that if the account exists, the program continues without error.
## Detection
- **Indicators of Compromise:** Frequent transaction failures with `IllegalOwner` errors or `ProgramError` during ATA creation steps.
- **Detection methods and tools:** Audit `#[derive(Accounts)]` structs for the presence of `init` on accounts using `associated_token::mint` or `associated_token::authority`.
## References
- **Vendor Advisory:** [https://taichiaudit.com/blog/solana-security-series-2](hXXps://taichiaudit.com/blog/solana-security-series-2)
- **Anchor Documentation:** [hXXps://www.anchor-lang.com/docs/account-constraints](hXXps://www.anchor-lang.com/docs/account-constraints)
- **Solana SPL Token:** [hXXps://spl.solana.com/associated-token-account](hXXps://spl.solana.com/associated-token-account)