Biconomy — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Biconomy, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 15
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 15 closed, publicly disclosed Biconomy reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Signature replay, Reentrancy, Front-running / MEV, Logic error, Access control, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Signature replay findings disclosed against Biconomy
- Reentrancy findings disclosed against Biconomy
- Front-running / MEV findings disclosed against Biconomy
- Logic error findings disclosed against Biconomy
- Access control findings disclosed against Biconomy
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Biconomy: Destruction of the `SmartAccount` implementation
An uninitialized logic implementation contract in Biconomy's SmartAccount allows any external attacker to call `init` and claim ownership of the base implementation contract. Once ownership is gained, the attacker can execute a `delegatecall` to a malicious contract containing a `selfdestruct` instruction. Destroying the logic implementation contract permanently freezes all proxy user wallets relying on this implementation, bricking funds across all deployed smart accounts.
Biconomy: `FeeRefund.tokenGasPriceFactor` is not included in signed transaction data allowing the submitter to steal funds
In Biconomy SmartAccount, relayers execute user transactions and receive token refunds calculated via the formula `(gasUsed + baseGas) * gasPrice / tokenGasPriceFactor`. While user signatures authorise transaction parameters to prevent relayer overcharging, `tokenGasPriceFactor` was omitted from the EIP-712 structured hash created by `encodeTransactionData()`. This allowed malicious transaction submitters to manipulate `tokenGasPriceFactor` at execution time—such as reducing it from 18 to 1—draining significantly higher token amounts from the user wallet than signed for.
Biconomy: Replay attack (EIP712 signed transaction)
Biconomy's SmartAccount contract allowed authorization signatures to be replayed across different batch keys. Because the batch identifier was passed as an external parameter to transaction execution rather than included in the EIP-712 signature digest calculation, an attacker could submit a valid signed transaction against any uninitialized batch ID sharing the same nonce sequence. This allowed initial user transactions to be replayed indefinitely across up to 2^256 potential batch channels, leading to unauthorized duplicate execution of transfer and wallet operations.
Biconomy: Theft of funds under relaying the transaction
In Biconomy's SmartAccount contract, relayed transactions compute gas refunds using an assumed average gas cost of 8 gas per calldata byte. An attacker can front-run legitimate relayed transactions and append zero-padded trailing bytes to the calldata. Because zero bytes only cost 4 gas in EVM gas economics, the contract over-reimburses the submitter relative to the actual gas spent. This allows malicious actors to systematically overcharge user wallets for transaction fees and siphon funds during execution relaying.
Biconomy: DoS of user operations and loss of user transaction fee due to insufficient gas value submission by malicious bundler
In Biconomy's ERC-4337 EntryPoint implementation, a malicious bundler could execute `handleOps` with an insufficient outer gas allowance. Because the EntryPoint did not enforce that `gasleft()` was strictly greater than the user operation's specified gas limits before invoking `callGasLimit`, the inner execution would run out of gas and revert. Despite the execution failure, post-operation accounting would still deduct transaction fees from the user or paymaster, resulting in loss of funds and denial of service.
Biconomy: Non-compliance with EIP-4337
Biconomy's account abstraction smart contracts suffered from standard non-compliance issues relative to the EIP-4337 specification. Specifically, the contract failed to enforce non-empty initialization code when interacting with uncreated sender accounts, reverted on signature mismatches instead of returning standardized validation flags, and omitted required aggregator verification checks. These compliance flaws disrupted normal interactions with off-chain bundlers and gas estimation infrastructure.
All reports in this group
- Biconomy: Arbitrary transactions possible due to insufficient signature validationLogic error$0
- Biconomy: Transaction can fail due to batchId collisionLogic error$0
- Biconomy: Attacker can gain control of counterfactual walletFront-running / MEV$0
- Biconomy: Doesn't Follow ERC1271 StandardLogic error$0
- Biconomy: Griefing attacks on `handleOps` and `multiSend` logicFront-running / MEV$0
- Biconomy: Methods used by EntryPoint has `onlyOwner` modifierAccess control$0
- Biconomy: Cross-Chain Signature Replay AttackSignature replay$0
- Biconomy: Paymaster ETH can be drained with malicious senderLogic error$0
- Biconomy: `SmartAccount.sol` is intended to be upgradable but inherits from contracts that contain storage and no gapsLogic error$0