RustSec flags two anchor-lang bugs in Solana account validation

How many times can the same abstraction fail before it stops looking like a helper and starts looking like a warning label? In `anchor-lang`, twice in two days. RustSec flagged two closely spaced advisories in mid-May 2026, and both traced back to the same core problem: account validation that looked strict on the surface, then collapsed under a small mismatch in how Anchor handled metadata.

The first advisory, issued May 18, covered `Program<System>` accepting arbitrary executable programs in affected releases before 1.0.2. The bug lived in a generic validation path that used `Pubkey::default()` as a sentinel, which collided with the system program’s own default pubkey. That collision meant `Program<'info, System>` was treated like the untyped `Program<'info>` case and could accept any executable program account. In Solana code, that is not a harmless edge case. Developers lean on the typed wrapper to make sure CPI calls, instruction builders, payments, and account-creation flows actually point at the real system program, not an account an attacker has smuggled in.

The second advisory, issued May 19, was different in mechanism but familiar in shape. `InterfaceAccount` bypassed checked deserialization, so the wrapper verified only that the owner matched one of the accepted interface owners, not that the account data belonged to the expected type. That opened the door to a mix-up where an attacker could supply another account type owned by an accepted program and still get it deserialized through the interface wrapper. The result could be incorrect authorization or state handling, which is exactly the kind of bug that slips past tests when the account owner looks right and the data shape does not get fully checked.

The fix in `1.0.0-rc.2` restored checked deserialization for `InterfaceAccount::try_from` and kept explicitly unchecked behavior behind an unchecked API. That distinction matters. Anchor’s ergonomics are part of why so many Solana programs use it, but they can also lull developers into trusting structure over invariants. A typed wrapper can feel like a security boundary, especially when the code reads cleanly and the account type names line up.

These two advisories make the same point from different angles: in Solana, the wrapper is not the guarantee. The guarantee is the validation behind it. If `anchor-lang` can be tripped twice in quick succession by the same trust mistake, every program that depends on Anchor needs a fresh audit of where typed accounts are being assumed, not proved.