MEV on all Balancer actions - join, exit, swap are not slippage protected and can be sandwich attacked
Summary
The codebase has an integration with Balancer vaults and makes heavy use of the join, exit and swap actions, but they have 0 slippage protection and can be sandwich attacked every time
Vulnerability Detail
All Balancer actions usually take a "maxValueIn" or "minValueOut" parameter, but the code does not use them, either passing 0 or an empty value. This means every time a user interacts with the protocol through a method that does a Balancer action (almost all of the methods) he can get sandwich attacked and lose a lot of value. MEV bots are scanning the mempool and when they see a transaction with no slippage protection they have automations to take flash loans, so a large amount of liquidity, and sandwich attack those trades/actions, resulting in value stolen from users.
Impact
The impact can be very big value losses for users of the protocol, since they can be sandwiched with flash loans on each of their transactions and have 90%+ slippage. Since no special conditions need to occur but users can lose value I choose High severity.
pashov
high
MEV on all
Balanceractions -join,exit,swapare not slippage protected and can be sandwich attackedSummary
The codebase has an integration with Balancer vaults and makes heavy use of the
join,exitandswapactions, but they have 0 slippage protection and can be sandwich attacked every timeVulnerability Detail
All Balancer actions usually take a "maxValueIn" or "minValueOut" parameter, but the code does not use them, either passing
0or an empty value. This means every time a user interacts with the protocol through a method that does a Balancer action (almost all of the methods) he can get sandwich attacked and lose a lot of value. MEV bots are scanning the mempool and when they see a transaction with no slippage protection they have automations to take flash loans, so a large amount of liquidity, and sandwich attack those trades/actions, resulting in value stolen from users.Impact
The impact can be very big value losses for users of the protocol, since they can be sandwiched with flash loans on each of their transactions and have 90%+ slippage. Since no special conditions need to occur but users can lose value I choose High severity.
Code Snippet
https://github.com/sherlock-audit/2022-11-sense/blob/main/contracts/src/AutoRoller.sol#L736 https://github.com/sherlock-audit/2022-11-sense/blob/main/contracts/src/AutoRoller.sol#L307 https://github.com/sherlock-audit/2022-11-sense/blob/main/contracts/src/AutoRoller.sol#L231
Tool used
Manual Review
Recommendation
Add a parameter to each function for
minValueOutormaxValueInor force users to use a private mempool (at least through a notice in docs)Duplicate of #45