Listen to this Post
The vulnerability resides in Kora’s `verify_token_payment()` function, which validates whether a user has paid sufficient transaction fees using an SPL Token-2022 token that includes a `TransferFeeConfig` extension. When a user initiates a `transfer_checked` instruction, the on-chain Token-2022 program automatically deducts a configured transfer fee (e.g., 5%) from the specified amount and credits only the net amount to the paymaster’s destination account. However, `verify_token_payment()` extracts the raw `amount` from the instruction and uses this pre-fee value to compute the equivalent lamport value via calculate_token_value_in_lamports(). The function never subtracts the transfer fee, so the paymaster credits the full raw amount as payment, while actually receiving amount - transfer_fee. This discrepancy causes the paymaster to systematically over-credit value for every transaction paid with a fee‑bearing Token‑2022 token. Although the codebase contains a `calculate_transfer_fee()` function (used elsewhere for fee estimation), it is never invoked during payment verification. As a result, an attacker can pay less than the required fee by exploiting this asymmetry, causing the paymaster to suffer cumulative financial losses proportional to the transfer fee percentage.
dailycve form
Platform: Kora Paymaster
Version: Unspecified (pre‑patch)
Vulnerability: Token‑2022 fee miscalc
Severity: High
date: 2025-02-25
Prediction: Patch expected 2025-03-15
What Undercode Say:
Analytics
The flaw is a classic example of inconsistent state handling: the verification logic uses the gross transfer amount while the on‑chain program settles the net amount. For a token with a transfer fee of f basis points, the paymaster loses exactly f/10000 of every payment. Over many transactions, this loss accumulates linearly. The vulnerability exists only for Token‑2022 mints that have the `TransferFeeConfig` extension and are whitelisted in allowed_spl_paid_tokens. The test suite already includes such mints (e.g., `create_usdc_mint_2022` with 1% fee), making the issue easily reproducible.
Bash Commands & Code
- Check if a mint has transfer fees (using Solana CLI):
solana account <MINT_ADDRESS> --output json | jq '.data.parsed.info.extensions[] | select(.extension=="transferFeeConfig")'
- Simulate the loss (bash one‑liner for a 5% fee token):
fee_basis_points=500; amount=1000; fee=$((amount fee_basis_points / 10000)); net=$((amount - fee)); echo "Credited: $amount, Received: $net, Loss: $fee"
- Rust test snippet (from the ) to verify the discrepancy:
[tokio::test] async fn test_token2022_transfer_fee_not_deducted() { let transfer_amount: u64 = 1_000_000; let credited_amount = transfer_amount; let actual_received = transfer_amount - (transfer_amount 1000 / 10000); assert!(credited_amount > actual_received); }
How Exploit:
An attacker can craft a transaction that pays the required fee using a Token‑2022 token with a transfer fee. They send a `transfer_checked` instruction with an amount that, after the on‑chain fee deduction, delivers exactly the required net value to the paymaster. However, because `verify_token_payment()` uses the pre‑fee amount, it considers the payment sufficient even though the paymaster received less. The attacker thus pays less than the required fee. Repeating this for every transaction yields a steady drain of funds from the paymaster.
Protection from this CVE
The fix requires modifying `verify_token_payment()` to deduct the transfer fee before calculating the lamport value. The effective amount should be obtained by fetching the mint’s `TransferFeeConfig` and calling calculate_transfer_fee(), then subtracting that fee from the raw amount. The patched code would look like:
let effective_amount = if is_2022 {
let mint_info = Token2022MintInfo::from_account_data(&mint_account.data)?;
if let Ok(Some(fee)) = mint_info.calculate_transfer_fee(amount, current_epoch) {
amount.saturating_sub(fee)
} else { amount }
} else { amount };
Until the patch is applied, operators should avoid whitelisting any Token‑2022 mint that has a transfer fee, or temporarily disable Token‑2022 fee payments.
Impact
- Systematic Financial Loss: Every transaction using a fee‑bearing Token‑2022 token results in the paymaster crediting more value than it receives.
- Loss Scale: Proportional to the transfer fee percentage. For a 5% fee token, the paymaster loses 5% of every payment amount. Over 100 transactions of $1 each, that is $5 lost.
- Precondition: Requires a Token‑2022 mint with `TransferFeeConfig` to be whitelisted in
allowed_spl_paid_tokens. Many projects using SPL Token‑2022 may inadvertently enable this.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
