{"answers":{"affected":"2 open source packages ship an affected version, including kora-lib.","exploited":"There is no known exploitation of GHSA-725g-w329-g7qr in the wild and no public exploit code.","fix":"Upgrade kora-lib to 2.0.5 or later.","what":"GHSA-725g-w329-g7qr is a vulnerability in kora-lib, published on 12 Mar 2026. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-725g-w329-g7qr and fix it if it is affected.\n\nWhat it is: GHSA-725g-w329-g7qr is a vulnerability in kora-lib, published on 12 Mar 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-725g-w329-g7qr in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- kora-lib (crates.io): affected all versions; fixed in 2.0.5\n- kora-lib (crates.io): affected all versions; fixed in 2.0.5\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-725g-w329-g7qr/ (Markdown: https://insights.sbomify.com/GHSA-725g-w329-g7qr/index.md)","id":"GHSA-725g-w329-g7qr","markdown":"https://insights.sbomify.com/GHSA-725g-w329-g7qr/index.md","name":"GHSA-725g-w329-g7qr","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"patch","impacts":["data_modify"],"network_reachable":"yes","non_default_config":false,"product_category":"Solana payment library","requires_auth":"none","summary":"Kora library incorrectly credits full token amount during payment verification, ignoring transfer fees, leading to financial loss for paymasters.","user_interaction":"not_required","vuln_class":"business_logic"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"## Summary\n\nWhen a user pays transaction fees using a Token-2022 token with a `TransferFeeConfig` extension, Kora's `verify_token_payment()` credits the full raw transfer `amount` as the payment value. However, the on-chain SPL Token-2022 program withholds a portion of that amount as a transfer fee, so the paymaster's destination account only receives `amount - transfer_fee`. This means the paymaster consistently credits more value than it actually receives, resulting in systematic financial loss.\n\n## Severity\n\n**High**\n\n## Affected Component\n\n- **File:** `crates/lib/src/token/token.rs`\n- **Function:** `verify_token_payment()`\n- **Lines:** 529–654 (specifically 633–639)\n\n## Root Cause\n\nIn `verify_token_payment()`, the `amount` extracted from the parsed SPL transfer instruction is the **pre-fee** amount (what the sender specifies in the `transfer_checked` instruction). The function passes this raw amount to `calculate_token_value_in_lamports()` to determine how many lamports the payment is worth. It never subtracts the Token-2022 transfer fee.\n\nThe fee estimation path (`fee.rs:analyze_payment_instructions`) correctly accounts for transfer fees by calculating them and adding them to the total fee. But the verification path does not perform the inverse subtraction, creating an asymmetry.\n\n## Vulnerable Code\n\n```rust\n// crates/lib/src/token/token.rs:529-654\npub async fn verify_token_payment(\n    transaction_resolved: \u0026mut VersionedTransactionResolved,\n    rpc_client: \u0026RpcClient,\n    required_lamports: u64,\n    expected_destination_owner: \u0026Pubkey,\n) -\u003e Result\u003cbool, KoraError\u003e {\n    let config = get_config()?;\n    let mut total_lamport_value = 0u64;\n\n    // ...\n\n    for instruction in transaction_resolved\n        .get_or_parse_spl_instructions()?\n        .get(\u0026ParsedSPLInstructionType::SplTokenTransfer)\n        .unwrap_or(\u0026vec![])\n    {\n        if let ParsedSPLInstructionData::SplTokenTransfer {\n            source_address,\n            destination_address,\n            mint,\n            amount,      // \u003c-- This is the PRE-FEE amount from the instruction\n            is_2022,\n            ..\n        } = instruction\n        {\n            // ... destination validation ...\n\n            // LINE 633-639: Uses raw *amount without deducting transfer fee\n            let lamport_value = TokenUtil::calculate_token_value_in_lamports(\n                *amount,        // \u003c-- BUG: Should be (amount - transfer_fee)\n                \u0026token_mint,\n                config.validation.price_source.clone(),\n                rpc_client,\n            )\n            .await?;\n\n            total_lamport_value = total_lamport_value\n                .checked_add(lamport_value)\n                .ok_or_else(|| {\n                    KoraError::ValidationError(\"Payment accumulation overflow\".to_string())\n                })?;\n        }\n    }\n\n    Ok(total_lamport_value \u003e= required_lamports)\n}\n```\n\nFor comparison, the transfer fee calculation exists elsewhere in the codebase and is used during fee estimation:\n\n```rust\n// crates/lib/src/token/spl_token_2022.rs:165-198\npub fn calculate_transfer_fee(\n    \u0026self,\n    amount: u64,\n    current_epoch: u64,\n) -\u003e Result\u003cOption\u003cu64\u003e, KoraError\u003e {\n    if let Some(fee_config) = self.get_transfer_fee() {\n        let transfer_fee = if current_epoch \u003e= u64::from(fee_config.newer_transfer_fee.epoch) {\n            \u0026fee_config.newer_transfer_fee\n        } else {\n            \u0026fee_config.older_transfer_fee\n        };\n        let basis_points = u16::from(transfer_fee.transfer_fee_basis_points);\n        let maximum_fee = u64::from(transfer_fee.maximum_fee);\n        let fee_amount = (amount as u128)\n            .checked_mul(basis_points as u128)\n            .and_then(|product| product.checked_div(10_000))\n            // ...\n        Ok(Some(std::cmp::min(fee_amount, maximum_fee)))\n    } else {\n        Ok(None)\n    }\n}\n```\n\nThis function exists but is **never called** in `verify_token_payment()`.\n\n## Proof of Concept\n\n### Arithmetic Demonstration\n\nGiven:\n- Token-2022 token with 5% transfer fee (500 basis points), whitelisted in `allowed_spl_paid_tokens`\n- Transaction fee cost: 5000 lamports equivalent\n- Token price: 1 token = 5 lamports\n\n**What should happen:**\n- User needs to pay 5000 lamports worth → 1000 tokens\n- Transfer fee on 1000 tokens at 5% = 50 tokens\n- Paymaster destination receives: 1000 - 50 = 950 tokens (worth 4750 lamports)\n- User should be required to pay MORE to cover the fee\n\n**What actually happens:**\n- User sends `transfer_checked` for `amount = 1000` tokens\n- `verify_token_payment()` calculates: 1000 tokens * 5 lamports/token = 5000 lamports\n- 5000 \u003e= 5000 required → **payment verified as sufficient**\n- But paymaster only received 950 tokens (worth 4750 lamports)\n- **Paymaster lost 250 lamports on this transaction**\n\n**Over 1000 transactions:** Paymaster loses 250,000 lamports (0.25 SOL)\n\n### Runnable Test (using existing test infrastructure)\n\n```rust\n#[tokio::test]\nasync fn test_token2022_transfer_fee_not_deducted_in_verification() {\n    // Setup: Token-2022 mint with 10% transfer fee (1000 bps)\n    let transfer_fee_config = create_transfer_fee_config(\n        1000,      // 10% basis points\n        u64::MAX,  // no maximum fee cap\n    );\n\n    let mint_pubkey = Pubkey::new_unique();\n    let mint_account = MintAccountMockBuilder::new()\n        .with_decimals(6)\n        .with_supply(1_000_000_000_000)\n        .with_extension(ExtensionType::TransferFeeConfig)\n        .build_token2022();\n\n    // User sends transfer_checked for 1,000,000 tokens (1 token at 6 decimals)\n    let transfer_amount: u64 = 1_000_000;\n\n    // What verify_token_payment credits:\n    let credited_amount = transfer_amount;  // = 1,000,000\n\n    // What the paymaster actually receives (after 10% on-chain fee):\n    let actual_received = transfer_amount - (transfer_amount * 1000 / 10000);  // = 900,000\n\n    // BUG: credited_amount (1,000,000) \u003e actual_received (900,000)\n    // Paymaster is credited 11.1% MORE than it actually receives\n    assert!(credited_amount \u003e actual_received);\n    assert_eq!(credited_amount - actual_received, 100_000); // 100,000 token units lost\n\n    // The financial loss per transaction = 10% of the payment amount\n    // This is NOT a rounding error — it is a full percentage-based loss\n}\n```\n\n## Impact\n\n- **Systematic Financial Loss:** The paymaster consistently credits more token value than it receives for every transaction paid with a transfer-fee-bearing Token-2022 token.\n- **Loss Scale:** Proportional to `transfer_fee_basis_points / 10000 * payment_amount` per transaction. For a token with 5% fee and 100 transactions/day at $1 each, that is $5/day or $1,825/year in losses.\n- **Precondition:** Requires a Token-2022 token with `TransferFeeConfig` extension to be whitelisted in `allowed_spl_paid_tokens`. The existing test infrastructure already creates such tokens (`TestAccountSetup::create_usdc_mint_2022()` with 100 bps / 1% fee).\n\n## Recommendation\n\nDeduct the Token-2022 transfer fee before calculating the lamport value of the payment:\n\n```rust\n// In verify_token_payment(), after extracting amount:\nlet effective_amount = if *is_2022 {\n    // Fetch the mint to check for TransferFeeConfig\n    let mint_account = CacheUtil::get_account(\n        rpc_client,\n        \u0026token_mint,\n        false,\n    ).await?;\n    let mint_info = Token2022MintInfo::from_account_data(\u0026mint_account.data)?;\n\n    if let Ok(Some(fee)) = mint_info.calculate_transfer_fee(\n        *amount,\n        rpc_client.get_epoch_info().await?.epoch,\n    ) {\n        amount.saturating_sub(fee)\n    } else {\n        *amount\n    }\n} else {\n    *amount\n};\n\nlet lamport_value = TokenUtil::calculate_token_value_in_lamports(\n    effective_amount,  // Use post-fee amount\n    \u0026token_mint,\n    config.validation.price_source.clone(),\n    rpc_client,\n)\n.await?;\n```\n\n## References\n\n- `crates/lib/src/token/token.rs:529-654` — `verify_token_payment()` using raw amount\n- `crates/lib/src/token/spl_token_2022.rs:165-198` — `calculat","ecosystems":["crates.io"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"kora-lib: Token-2022 Transfer Fee Not Deducted During Payment Verification","id":"GHSA-725g-w329-g7qr","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"crates.io","product":null,"products":[],"type":"business_logic","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"crates.io","fixed":["2.0.5"],"introduced":["0"],"last_affected":[],"package":"kora-lib","purl":null,"source":"GHSA-725g-w329-g7qr"},{"ecosystem":"crates.io","fixed":["2.0.5"],"introduced":["0"],"last_affected":[],"package":"kora-lib","purl":"pkg:cargo/kora-lib","source":"GHSA-725g-w329-g7qr"}],"products":null,"published":"2026-03-12","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Kora library incorrectly credits full token amount during payment verification, ignoring transfer fees, leading to financial loss for paymasters.","url":"https://insights.sbomify.com/GHSA-725g-w329-g7qr/"}