fix: F-2026-18198 | [Dual Defense] Solana Inbound Event Forgery Enables Unbacked Synthetic Minting

[Aman035]

F-2026-18198 Solana inbound event forgery

Issue

• getSignaturesForAddress(gateway) returns any tx that merely references the gateway in accountKeys.
• We accepted any Program data: line whose 8 byte discriminator matched. A discriminator is a schema tag, not an authenticator.
• So any program could emit a well formed gateway event and every honest UV would vote for it. Unbacked mint, no validator compromise needed.

Approach taken

• gatewayEmittedLogs walks the runtime invoke / success / failed: lines as a stack and accepts a Program data: line only while the gateway is the executing frame.
• Sound because programs cannot forge those lines: sol_log always prefixes Program log: and sol_log_data always prefixes Program data: , so bare invoke/exit lines are runtime generated. Asserted in a test, not assumed.
• Our first attempt let Program log: success pop a frame it did not own, so a gateway callee could steal attribution. Fixed by requiring the token before the verb to parse as a base58 pubkey.

Log truncation

Detection only (logsTruncated), deliberately. Measured 72,175 mainnet txs across 54 blocks: none truncated, p99 7,382 bytes, max 13,897. A gateway deposit is ~700 bytes. Reaching the cap means padding your own tx, which strands your own deposit for no gain, and cannot be done to someone else's.

Tests

• Rejected: the reported attack (attacker program emits a valid discriminator while only referencing the gateway), log after the gateway frame exits, log after a failed invocation, spoofed invoke line, callee popping its own frame, unbalanced exits.
• Accepted: gateway log, gateway frame reached via CPI, unrelated runtime lines leaving the stack undisturbed.
• Mutation checked: removing the attribution condition fails five tests including the forgery case; removing the stack underflow guard panics.