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 CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Reentrancy, Front-running / MEV, Signature replay, 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
- Logic error findings disclosed against Biconomy
- Reentrancy findings disclosed against Biconomy
- Front-running / MEV findings disclosed against Biconomy
- Signature replay 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: `SmartAccount.sol` is intended to be upgradable but inherits from contracts that contain storage and no gaps
Biconomy's SmartAccount contract inherits from base contracts such as ModuleManager that hold state variables but omit storage gaps. In an upgradeable smart contract architecture, modifying state variables in base contracts without reserved storage gaps causes storage layout collisions across upgrades. This vulnerability could lead to state corruption and corrupted account storage layout if new storage variables are introduced in future contract versions.
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.
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: Attacker can gain control of counterfactual wallet
Biconomy's SmartAccountFactory allows counterfactual smart accounts to be pre-funded before deployment. However, the CREATE2 deployment salt for `deployCounterFactualWallet` only binds the owner address and index, excluding the entryPoint and handler parameters. An attacker can front-run or deploy a user's pre-computed wallet address using a malicious entryPoint contract, gaining execution control over the account and stealing any assets sent to the counterfactual address prior to deployment.
Biconomy: Cross-Chain Signature Replay Attack
Biconomy's VerifyingSingletonPaymaster omitted the chain ID from its internal user operation hash calculation in getHash(). Because paymaster signatures did not commit to a specific EVM chain ID, valid sponsorship signatures generated for a user operation on one chain could be replayed across other EVM chains where the same paymaster and wallet deployed. This allowed attackers or malicious wallet users to drain gas sponsorship funds from the paymaster contract across multiple network deployments.
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.
All reports in this group
- Biconomy: DoS of user operations and loss of user transaction fee due to insufficient gas value submission by malicious bundlerLogic error$0
- Biconomy: Arbitrary transactions possible due to insufficient signature validationLogic error$0
- Biconomy: Transaction can fail due to batchId collisionLogic error$0
- Biconomy: Paymaster ETH can be drained with malicious senderLogic error$0
- Biconomy: Methods used by EntryPoint has `onlyOwner` modifierAccess control$0
- Biconomy: Theft of funds under relaying the transactionFront-running / MEV$0
- Biconomy: Destruction of the `SmartAccount` implementationSignature replay$0
- Biconomy: Doesn't Follow ERC1271 StandardLogic error$0
- Biconomy: Griefing attacks on `handleOps` and `multiSend` logicFront-running / MEV$0