Cross-Program Invocation (CPI) Security Best Practices

Adapt the classic Ethereum security pattern for Solana's atomic transaction model. Perform all account validation and state updates before making any CPI to external programs. Because all instructions in a Solana transaction execute atomically, a malicious callee cannot front-run state changes, but it can re-enter your program through nested CPIs. Complete state transitions first, then invoke external programs. This prevents re-entrancy from operating on stale or intermediate state.

Never invoke an untrusted or upgradeable program with your program's full signer privileges. When your program holds a PDA-derived signer, limit the scope of what that signer authorizes. Use seeds with domain separation so a signer intended for one protocol cannot be misused by another. If invoking an unknown program, consider whether the CPI should happen at all—or whether the user should sign directly. The most common privilege escalation bugs involve programs blindly forwarding PDA signers to arbitrary callees.

Solana allows up to 4 levels of CPI depth. A malicious program invoked by your program can call back into your program before the first invocation completes. Mitigate this by: (1) completing all state changes before external CPIs, (2) using a re-entrancy guard flag stored in account data that is checked and set atomically, and (3) assuming any external call could trigger recursive execution. Anchor's #[account(init)] pattern provides some protection, but custom guards are essential for complex multi-CPI workflows.

Start with the Solana CPI documentation to confirm how programs invoke other programs, how account privileges are forwarded, and how signer and writable flags behave across nested calls. For security review, convert this into an invocation map: every CPI target, every account passed through, every signer privilege, and every writable privilege should have an explicit reason. Pay particular attention to user-supplied program IDs and account metas, because arbitrary CPI bugs usually arise when a program trusts an external instruction path without pinning the invoked program or validating account ownership.

CPI security often depends on whether a Program Derived Address is being used as a controlled signer. The Solana PDA documentation is the source to review for deterministic address derivation, bump handling, and signing with seeds during cross-program calls. Builders should verify that PDA seeds are domain-separated, include the correct authority or state identifiers, and cannot be reused across unrelated trust domains. Auditors should check that programs never treat any PDA-looking address as valid without recomputing the derivation and confirming the account owner and expected bump.

Anchor's CPI documentation is useful when reviewing programs that build CpiContext objects, call generated CPI clients, or pass accounts through remaining_accounts. The security action is not just to confirm the syntax works; reviewers should inspect whether Anchor constraints actually bind the account to the expected program, mint, token account, authority, or PDA. remaining_accounts deserves special scrutiny because it can bypass strongly typed account structs and may allow unexpected CPI targets or duplicate mutable accounts unless the program performs manual validation.

The Solana program security material is a practical source for known bug classes that appear in CPI-heavy code: arbitrary CPI, missing owner checks, PDA misuse, signer authorization mistakes, and duplicate mutable account handling. Treat it as a checklist input for threat modeling rather than as a substitute for audit. For each external invocation, teams should ask whether the callee can be swapped, upgraded, re-entered through another path, or supplied with accounts that cause state changes outside the caller's intended invariant.

When implementation details matter, use the Agave source repository to verify current runtime behavior rather than relying on secondary summaries. This is relevant for CPI call-stack behavior, account loading, privilege escalation checks, compute metering, and how instruction processing rejects invalid account metas. Protocol teams should reference the exact client version they test against, especially when preparing for runtime upgrades or feature activations that may change enforcement details. Security teams should pair source review with local tests using solana-program-test or a controlled validator environment.

Many high-risk CPIs on Solana target token programs, so teams should keep the SPL Token documentation close during integration review. Use it to verify authority models, token account ownership, delegate behavior, mint configuration, and expected instruction semantics before invoking token transfers, burns, mints, closes, or approvals. For production programs, explicitly distinguish legacy SPL Token from Token-2022 where relevant, validate the token program ID, and account for extension behavior before assuming a token account behaves like the legacy interface.