A malicious user could potentially exploit certain conditions to cause functions like validatePaymasterUserOp to revert consistently. If these reverts happen frequently, it could lead to the paymaster being flagged, deprioritized by the EntryPoint, or even banned due to perceived unreliability.
Proof of Concept
A bad actor could say observe a pending transaction in the bundler mempool that will significantly reduce the paymaster's balance, for instance a large withdrawal by a legitimate user. Before this transaction is mined, the frontrunner executes another transaction that further depletes the contract's balance. This action could make the original transaction fail due to insufficient funds.
if (address(this).balance < withdrawAmount) {
revert InsufficientBalance(withdrawAmount, address(this).balance);
}
The EntryPoint relies on validatePaymasterUserOp to not revert under normal operation. Consistent reverts, especially due to balance issues caused by frontrunning, signal to the EntryPoint that the paymaster is unreliable.
Scenario
Front-runners monitor the mempool for transactions indicating significant balance changes or withdrawals from the paymaster. They then submit their transactions with higher gas fees which leads to their transactions being mined before the observed transactions.
This frontrunning can cause legitimate transactions to fail due to changed state conditions like insufficient balance, which in turn could cause validatePaymasterUserOp to revert consistently. Consequently signaling to Entrypoint that the paymaster is unreliable leading to it been banned or unprioritized for future transactions in the network.
Tools Used
Manual Review
Recommended Mitigation Steps
Use private transaction relayers or services like Flashbots to prevent frontrunners from observing and exploiting transactions in the public mempool.
Maintain a buffer of funds that are not immediately visible or accessible through withdrawal requests. This buffer can help ensure that observed transactions in the mempool do not lead to state changes that cause subsequent transactions to fail.
Lines of code
https://github.com/code-423n4/2024-03-coinbase/blob/main/src/MagicSpend/MagicSpend.sol#L109
Vulnerability details
Impact
A malicious user could potentially exploit certain conditions to cause functions like
validatePaymasterUserOp
to revert consistently. If these reverts happen frequently, it could lead to the paymaster being flagged, deprioritized by the EntryPoint, or even banned due to perceived unreliability.Proof of Concept
A bad actor could say observe a pending transaction in the bundler mempool that will significantly reduce the paymaster's balance, for instance a large withdrawal by a legitimate user. Before this transaction is mined, the frontrunner executes another transaction that further depletes the contract's balance. This action could make the original transaction fail due to insufficient funds.
Github link
The EntryPoint relies on validatePaymasterUserOp to not revert under normal operation. Consistent reverts, especially due to balance issues caused by frontrunning, signal to the EntryPoint that the paymaster is unreliable.
Scenario
Front-runners monitor the mempool for transactions indicating significant balance changes or withdrawals from the paymaster. They then submit their transactions with higher gas fees which leads to their transactions being mined before the observed transactions.
This frontrunning can cause legitimate transactions to fail due to changed state conditions like insufficient balance, which in turn could cause
validatePaymasterUserOp
to revert consistently. Consequently signaling to Entrypoint that the paymaster is unreliable leading to it been banned or unprioritized for future transactions in the network.Tools Used
Manual Review
Recommended Mitigation Steps
Use private transaction relayers or services like Flashbots to prevent frontrunners from observing and exploiting transactions in the public mempool.
Maintain a buffer of funds that are not immediately visible or accessible through withdrawal requests. This buffer can help ensure that observed transactions in the mempool do not lead to state changes that cause subsequent transactions to fail.
Assessed type
DoS