GHSA-725G-W329-G7QR: Token-2022 Transfer Fee Bypass in Solana Kora Relayer

The Solana Kora Relayer functions as an on-chain paymaster, allowing users to abstract away the native network fee (SOL) by paying for transaction costs using supported SPL tokens. The kora-lib crate handles the core verification logic, ensuring that the incoming token transfer from the user accurately covers the outgoing SOL fee expended by the relayer infrastructure.

The SPL Token-2022 program introduced several new extensions to the standard token specification, including the Transfer Fee extension. This extension allows token creators to configure a fee that is automatically deducted by the runtime during any transfer operation. Consequently, a transfer instruction specifying an amount of N tokens will result in the recipient receiving N - fee tokens.

The vulnerability exists within the payment verification flow of kora-lib. The software incorrectly calculates the user's payment validity by inspecting the transfer instruction's requested amount, rather than the final settled amount post-fee deduction. The system effectively credits the user for tokens that the relayer never receives, creating an economic imbalance that favors the transacting user at the expense of the paymaster.

This behavior is classified under CWE-682: Incorrect Calculation. The vulnerability specifically targets the relayer's economic model rather than traditional memory safety or authorization controls, but the impact directly compromises the operational viability of any affected Kora Relayer instance.

The root cause of this vulnerability spans two distinct implementation errors within the instruction parsing and payment verification pipeline. The first error involves the misidentification of program payloads due to an incorrect struct field reference in instruction_util.rs. The code compared the parsed.program string against the known program IDs for spl_token and spl_token_2022, failing to utilize the correct parsed.program_id field. This resulted in the relayer entirely failing to identify and reconstruct certain token instructions.

The second and primary issue relates to how legacy Transfer instructions are processed when dealing with Token-2022 assets. Unlike TransferChecked instructions, legacy Transfer instructions do not explicitly include the mint address in the instruction payload. Without the mint address, the relayer cannot query the on-chain TransferFeeConfig extension to determine the required fee deduction.

Because the verification logic operated solely on the instruction data provided in the transaction payload, it lacked the necessary state context. The code assumed that the amount specified in the instruction data perfectly mirrored the balance change that would occur in the relayer's receiving token account.

This stateless verification model is fundamentally incompatible with Token-2022 transfer fees. The runtime enforces the fee dynamically based on the mint's current configuration at execution time. By skipping the RPC fetch required to resolve the missing mint address and calculate the fee, the verification logic defaulted to a zero-fee assumption, cementing the logic flaw.

The vulnerability manifests prominently in crates/lib/src/transaction/instruction_util.rs during the instruction reconstruction phase. The faulty dispatch logic misidentified the program ID due to a field mismatch:

// Pre-fix: Vulnerable dispatch logic
if parsed.program_id == SYSTEM_PROGRAM_ID.to_string() {
    Self::reconstruct_system_instruction(parsed, &account_keys_hashmap).ok()
} else if parsed.program == spl_token_interface::ID.to_string() 
    || parsed.program == spl_token_2022_interface::ID.to_string()
{
    // BUG: parsed.program used instead of parsed.program_id
    Self::reconstruct_spl_token_instruction(parsed, &account_keys_hashmap).ok()
}

The fix deployed in commit 8cbd8217ee505e6b37c63ef835ff095cfa8ab318 addresses both the field comparison error and the missing state resolution for the mint address. The patched crates/lib/src/token/token.rs now performs an asynchronous RPC call to fetch the source account state when the mint is not explicitly provided in the instruction:

// Post-fix: Mint resolution logic
let mint_pubkey = if let Some(m) = mint {
    *m
} else {
    // Resolve mint by fetching the source account state via RPC
    let source_account = CacheUtil::get_account(rpc_client, source_address, false).await?;
    let token_program = TokenType::get_token_program_from_owner(&source_account.owner)?;
    let token_account = token_program.unpack_token_account(&source_account.data)?;
    token_account.mint()
};
 
mint_to_transfers.entry(mint_pubkey).or_default().push((*amount, true));

By ensuring the mint_pubkey is always resolved, the subsequent verification steps can reliably invoke calculate_transfer_fee using the on-chain configuration. The patch effectively transitions the payment verification from a purely stateless operation to a state-aware process that accurately predicts the final execution outcome.

To exploit this vulnerability, an attacker must interact with a Kora Relayer instance that accepts a Token-2022 asset configured with a non-zero transfer fee. The attacker initiates the exploit by crafting a transaction that requires fee sponsorship from the relayer.

The critical step in the exploit involves formatting the token payment instruction. The attacker deliberately uses a legacy Transfer instruction rather than a TransferChecked instruction. This omits the mint address from the instruction payload, exploiting the missing mint resolution logic in the vulnerable relayer version.

The attacker specifies a transfer amount that perfectly matches the relayer's required payment quote for the transaction. Upon receiving the transaction, the relayer parses the instruction, observes the correct amount, and approves the transaction for sponsorship, signing it and submitting it to the Solana network.

During on-chain execution, the Token-2022 program intercepts the transfer, reads the mint's TransferFeeConfig, and deducts the configured percentage. The relayer's token account receives the post-fee amount, while the relayer pays the full SOL fee for the transaction execution. The attacker successfully executes their transaction while underpaying the required token equivalence.

The primary impact of this vulnerability is systemic financial loss for the operator of the affected Kora Relayer. While the vulnerability does not expose the host system to arbitrary code execution or permit unauthorized access to private keys, it directly undermines the economic security of the relayer infrastructure.

Because the exploitation process relies entirely on standard on-chain program interactions, it can be automated and executed repeatedly at high volume. An attacker could theoretically drain the relayer's SOL reserves by continuously submitting transactions that trigger maximum transfer fee deductions on the token payment side.

The following interaction model illustrates the economic disparity introduced by the vulnerability:

Operators utilizing tokens with high transfer fees as accepted payment methods face the highest risk. Tokens with transfer fees set near the maximum permissible limits would cause rapid depletion of the relayer's operating capital, forcing service degradation or offline status once the SOL fee payer account is emptied.

The definitive remediation for this vulnerability requires updating the kora-lib dependency to a version inclusive of commit 8cbd8217ee505e6b37c63ef835ff095cfa8ab318. Recompiling and redeploying the relayer binary guarantees that the updated mint resolution and fee calculation logic is actively enforced during the payment verification pipeline.

For operators unable to immediately deploy the patched software, a viable mitigation strategy involves restricting the accepted payment tokens. Operators should temporarily remove any Token-2022 assets from their accepted asset list, particularly those known to utilize the Transfer Fee extension. Limiting operations to standard SPL Token assets entirely bypasses the vulnerable code paths.

Additionally, relayer operators should implement out-of-band monitoring to track the discrepancy between anticipated token receipts and actual balance changes. Tracking these metrics provides immediate visibility into exploitation attempts and helps quantify any historical financial loss that may have occurred prior to patching.

Security teams reviewing custom paymaster implementations on Solana should ensure that all verification logic accurately mirrors the strict execution semantics of the underlying token programs. Relying solely on transaction instruction data without validating the corresponding on-chain state frequently leads to similar accounting bypasses.