CVE-2026-45137 Overview
CVE-2026-45137 affects Anchor, a framework for writing Solana programs. The vulnerability is a logic error in the TryFrom<&'a AccountInfo<'a>> for Program<'a, T> implementation. Anchor programs accept any executable account when they should require the Solana system program. Attackers can pass arbitrary programs in place of the system program, enabling arbitrary Cross-Program Invocation (CPI) or payment bypass. The flaw affects versions 1.0.0 up to but not including 1.0.2 and is fixed in 1.0.2. The issue is classified under [CWE-20] Improper Input Validation.
Critical Impact
Anchor programs invoking Program<'a, System> may execute CPI calls against attacker-controlled programs, leading to arbitrary CPI execution and payment bypass in on-chain Solana programs.
Affected Products
- Anchor framework versions 1.0.0 through 1.0.1
- Solana programs built with vulnerable Anchor versions that declare Program<'a, System> accounts
- Downstream Solana programs performing CPI to the system program via Anchor account validation
Discovery Timeline
- 2026-05-27 - CVE-2026-45137 published to NVD
- 2026-05-27 - Last updated in NVD database
Technical Details for CVE-2026-45137
Vulnerability Analysis
The vulnerability resides in Anchor's TryFrom<&'a AccountInfo<'a>> implementation for Program<'a, T>. Anchor compares the id of generic type T against Pubkey::default() to decide whether to allow any executable account or enforce a specific program id. When no T is supplied, T defaults to the unit type (), which implements Id::id() by returning Pubkey::default().
The System program also reports Pubkey::default() as its id. As a result, T = () and T = System produce identical runtime behavior. Both branches accept any executable account passed by the caller. Programs declaring Program<'a, System> therefore bypass the intended system program identity check.
Root Cause
The root cause is an ambiguous sentinel value. Anchor overloads Pubkey::default() to mean "no specific program required," while the system program legitimately uses the same default pubkey as its identifier. The runtime cannot distinguish between an unset type parameter and the System program type, collapsing two distinct validation paths into one permissive path.
Attack Vector
An attacker constructs a transaction targeting a vulnerable Anchor program that declares a Program<'a, System> account. Instead of supplying the genuine system program, the attacker supplies a malicious executable program account. Anchor's account validation accepts the substitution. When the victim program invokes a CPI such as system_program::transfer, the call dispatches to the attacker-controlled program. The attacker can short-circuit transfers, skip payments, or trigger arbitrary instructions in the substituted program.
No synthetic exploitation code is published in the advisory. See the GitHub Security Advisory GHSA-c6rc-8jpp-2fgc for the technical write-up.
Detection Methods for CVE-2026-45137
Indicators of Compromise
- Solana transactions invoking Anchor programs where the account at the system_program index does not equal 11111111111111111111111111111111.
- Unexpected CPI invocations originating from Anchor programs targeting non-system executable accounts.
- On-chain transfers that were expected but produced no lamport balance changes for the recipient.
Detection Strategies
- Audit deployed Anchor program source for use of Program<'a, System> and confirm the dependency version is 1.0.2 or later.
- Scan transaction logs for CPI dispatch to unknown program ids in slots where the system program was expected.
- Use static analysis on Anchor IDL output to enumerate account types declared as the system program and flag programs built against vulnerable Anchor releases.
Monitoring Recommendations
- Instrument Solana RPC consumers to alert when an Anchor program's systemProgram account argument deviates from the canonical system program pubkey.
- Track on-chain CPI graphs and flag programs that suddenly invoke unfamiliar callee program ids.
- Continuously inventory dependency manifests (Cargo.toml) across program repositories to detect Anchor versions in the vulnerable range.
How to Mitigate CVE-2026-45137
Immediate Actions Required
- Upgrade Anchor to version 1.0.2 or later in all Solana program workspaces.
- Rebuild and redeploy any program previously compiled with Anchor 1.0.0 or 1.0.1.
- Review existing programs for explicit pubkey checks against solana_program::system_program::ID and add them where missing.
Patch Information
The vulnerability is fixed in Anchor 1.0.2. The patch corrects the TryFrom<&'a AccountInfo<'a>> implementation for Program<'a, T> so that the System program type performs a direct pubkey equality check rather than relying on the Pubkey::default() sentinel. Refer to the GitHub Security Advisory GHSA-c6rc-8jpp-2fgc for patch commits and release notes.
Workarounds
- Add an explicit constraint such as #[account(address = system_program::ID)] to any Program<'a, System> account declaration as a defense-in-depth measure.
- Manually assert ctx.accounts.system_program.key() == &system_program::ID inside instruction handlers before any CPI call.
- Halt deployment of new programs built with vulnerable Anchor versions until the upgrade is complete.
# Update Anchor dependency to the patched release
cargo update -p anchor-lang --precise 1.0.2
cargo update -p anchor-spl --precise 1.0.2
anchor build
anchor deploy
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


