https://feed.craftedsignal.io/products/anchor-lang/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 13 May 2026 15:37:02 +0000https://feed.craftedsignal.io/briefs/2026-05-anchor-program-validation-bypass/Wed, 13 May 2026 15:37:02 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-anchor-program-validation-bypass/A logic error in anchor-lang versions 1.0.0 to 1.0.1 causes anchor programs to accept any program ID when requiring the system program ID, resulting in false assumptions that could lead to arbitrary CPI in programs invoking system program instructions, potentially leading to validation bypass and unauthorized account control.Anchor is a framework for building Solana programs. A validation vulnerability exists in anchor-lang versions 1.0.0 and 1.0.1 where programs built with anchor incorrectly validate the system_program account. Specifically, the TryFrom implementation for Program<'a, T> compares the ID of T with Pubkey::default() to check whether anchor should allow any executable account or a specific account. Due to this logic, both T = () and T = System exhibit the same behavior, allowing any executable account. This flaw allows attackers to pass arbitrary program IDs instead of the system program ID, causing false assumptions and enabling potential CPI and payment bypasses.

Attack Chain

1. Attacker identifies a vulnerable Anchor program (version 1.0.0 or 1.0.1) that uses the Program<'info, System> type to ensure a valid system program account.
2. The attacker crafts a malicious transaction, replacing the expected system program ID with the ID of a program they control (e.g., the Compute Budget program, or a custom program).
3. The vulnerable program’s Initialize function receives the attacker-provided program ID as the system_program account.
4. Due to the flawed validation logic, the Anchor runtime incorrectly accepts the attacker-provided program ID as a valid system program.
5. The vulnerable program constructs a transfer instruction using the (incorrect) attacker-supplied program ID.
6. The program invokes the transfer instruction, intending to transfer lamports using the system program. However, because the program ID is controlled by the attacker, no transfer occurs, or the transfer is redirected to an attacker-controlled program based on the malicious program logic.
7. The vulnerable program proceeds under the false assumption that the transfer has succeeded, potentially leading to incorrect state updates.
8. The attacker bypasses intended restrictions and potentially gains control of accounts meant to be owned by the system program, or blocks transfers.

Impact

This vulnerability impacts on-chain programs that depend on the system program, potentially leading to CPI bypasses and unauthorized payment diversions. This could result in financial losses and compromised program functionality. The vulnerability affects programs using rust/anchor-lang in versions 1.0.0 and 1.0.1. The severity of the vulnerability is rated as high due to the potential for significant financial impact and unauthorized account control.

Recommendation

• Upgrade rust/anchor-lang to version 1.0.2 or later to remediate the vulnerability.
• Deploy the provided Sigma rule Detect Anchor Program ID Validation Bypass to identify potential exploitation attempts targeting the vulnerable validation logic.
• Audit existing Anchor programs for improper system program account validation, specifically examining the TryFrom<&'a AccountInfo<'a>> implementation for Program<'a, T>.
• Use static analysis tools to detect vulnerable code patterns in Anchor programs that rely on system program interactions.

]]>highadvisoryanchorsolanaaccount-validationcpi-bypasshttps://feed.craftedsignal.io/briefs/2026-05-anchor-interfaceaccount-substitution/Wed, 13 May 2026 15:36:36 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-anchor-interfaceaccount-substitution/The `InterfaceAccount` in `anchor-lang` allows an unexpected account type to be passed due to disabled discriminator checking, patched in version 1.0.0-rc.2 and later.A vulnerability exists within the InterfaceAccount type in the anchor-lang package of the Anchor framework. This flaw allows for the substitution of account types because discriminator checking was unintentionally disabled in pull request #3837. An attacker could potentially exploit this by passing an account of an unexpected type, leading to unexpected behavior in Solana programs. The vulnerability affects version 1.0.0-rc.1. The fix was implemented in pull request #4139 and released in 1.0.0-rc.2. Users are strongly advised to upgrade to the latest released version of Anchor 1.0 to mitigate this risk. This impacts programs utilizing the Anchor framework on the Solana blockchain.

Attack Chain

1. An attacker identifies a Solana program utilizing InterfaceAccount with Anchor version 1.0.0-rc.1.
2. The attacker crafts a malicious transaction that attempts to pass an account of an incorrect type to the program via InterfaceAccount.
3. The program, lacking discriminator checking due to the vulnerability, accepts the incorrect account.
4. The program attempts to process the provided account based on the expected type.
5. Due to type mismatch, the program may experience unexpected behavior, such as data corruption.
6. The attacker leverages the corrupted data to manipulate program logic.
7. The attacker is able to perform unauthorized actions within the Solana program.
8. This can lead to financial loss, unauthorized data access, or denial of service for other users.

Impact

The vulnerability allows attackers to substitute account types in Solana programs using the Anchor framework’s InterfaceAccount, potentially leading to data corruption and unauthorized actions. This impacts any Solana program using the vulnerable InterfaceAccount in anchor-lang version 1.0.0-rc.1. Successful exploitation could result in financial loss, data breaches, or denial-of-service for users of the affected Solana programs.

Recommendation

• Upgrade to the latest released version of Anchor 1.0 (>= 1.0.0-rc.2) as described in the advisory to patch the vulnerable InterfaceAccount type.
• Examine your Solana programs for uses of InterfaceAccount in conjunction with anchor-lang 1.0.0-rc.1 and prioritize patching these programs.
• Monitor Solana program activity for unexpected account interactions and type mismatches as a potential indicator of exploitation.

]]>mediumadvisoryanchorsolanainterfaceaccountaccount-substitution