A blind scan caught Wormhole's sysvar bug and walked past Cashio's missing root of trust

The two bugs differ in where their evidence lives, and that difference is the whole result.

Wormhole's defect fits inside one struct field and two call sites. The account is declared untyped as `Info<'b>`, its data is parsed as the instructions sysvar by `load_current_index` and `load_instruction_at`, those are the only places the sysvar appears in the program, and there is no comparison against `sysvar::instructions::id()` ^[4]. Every fact a checker needs is local and decidable: a canonical address exists in the standard library, the code parses an account as if it were that address, the comparison is absent. The scanner reported it as the second of five findings, and the fix it proposed (typed `Sysvar<Instructions>` or an explicit key comparison) is the fix that shipped ^[3][5].

Cashio's defect is the absence of a root. `BrrrCommon::validate()` and `SaberSwapAccounts::validate()` run nine `assert_keys_eq!` checks, and every one of them compares two caller-supplied accounts to each other ^[8]. The checks are present and internally consistent, which is why an attacker who supplies the entire chain satisfies all nine ^[9]. Nine relative comparisons, zero anchored ^[3]. To call that wrong, a tool needs to know which account in the graph is supposed to be canonical, and the file does not say.

Except that the repository does say, once. `print_cash` compares `issue_authority` against a hardcoded `ISSUE_AUTHORITY_ADDRESS`, and that discipline was never applied to the bank and collateral chain ^[10]. The distinguishing property is therefore present in the same program: one validation path roots itself in a constant, the exploited path roots itself in nothing. A checker that compared anchoring discipline between paths of a single program would have had something to report. This one did not. It returned three findings, and the nearest was a Medium on `new_bank` being callable by anyone ^[11].

That Medium is the part worth arguing about. Permissionless `new_bank` is a real precondition of the attack ^[11]. The scanner then framed the risk as front-running the deployer to squat the canonical bank and closed with the line "If multiple banks are intentionally permissionless, document it and ignore this finding" ^[12]. Per the writeup, the attacker never front-ran anyone ^[13]. So the output was a true finding bolted to the wrong threat model, shipped with the exact sentence a maintainer would paste into the ticket while closing it.

Scorekeeping on the Wormhole half is more flattering but not clean. One of the five findings was the defect that cost $325M ^[2][1]. Three of the five carried severities that survived hand verification, and two were wrong in opposite directions ^[7][2]: a Critical on permissionless `initialize` that requires uninitialized bridge accounts on a bridge live since 2021 ^[6], and a Medium on fee front-running whose own source comment says the behaviour is deliberate ^[14]. The overrated Medium is the more instructive error. The tool read the code and not the comment sitting next to it.

The caveat the authors lead with belongs near the end too: these runs happened in 2026, on code whose outcome has been public for four years, both programs patched long ago ^[15]. It is a re-run against history, not a claim about February 2022.