The vulnerability in OperationalStaking allows a malicious validator to exploit transaction order by staking before and after the reward distribution, strategically claiming rewards meant for other validators. This front-running manipulation results in significant gains for the malicious actor, compromising the fairness of reward distribution
Vulnerability Detail
The OperationalStaking contains a vulnerability in the rewardValidators functions that exposes it to potential sandwich attacks, a form of front-running manipulation in transaction order. The vulnerability arises when the owner deposits reward tokens into the contract so when StakingManager subsequently triggering the reward distribution to validators.
If a malicious validator closely monitors the transaction pool and pending transactions, they can identify the rewardValidators transaction and called stake function to "buy/mint" alot of shares_tokens, right before the rewardValidators transaction immediately accrue a portion of the collected rewards that were meant to be attributed to other validators. so after reward is distribute among validators, The malicious validator can then immediately claim these rewards(redeemRewards), unstake. therefore the malicious validator stealing rewards from other validator.
Impact
The vulnerability allows a malicious validator to exploit transaction order, executing stake transactions strategically before and after reward distribution, leading to substantial gains through front-running and validator_shares manipulation.
hunter_w3b
high
Sandwich Attack in Reward Validators
Summary
The vulnerability in
OperationalStaking
allows a malicious validator to exploit transaction order by staking before and after the reward distribution, strategically claiming rewards meant for other validators. This front-running manipulation results in significant gains for the malicious actor, compromising the fairness of reward distributionVulnerability Detail
The
OperationalStaking
contains a vulnerability in therewardValidators
functions that exposes it to potential sandwich attacks, a form of front-running manipulation in transaction order. The vulnerability arises when the owner deposits reward tokens into the contract so whenStakingManager
subsequently triggering the reward distribution to validators. If a malicious validator closely monitors the transaction pool and pending transactions, they can identify therewardValidators
transaction and called stake function to "buy/mint" alot of shares_tokens, right before therewardValidators
transaction immediately accrue a portion of the collected rewards that were meant to be attributed to other validators. so after reward is distribute among validators, The malicious validator can then immediately claim these rewards(redeemRewards
), unstake. therefore the malicious validator stealing rewards from other validator.Impact
The vulnerability allows a malicious validator to exploit transaction order, executing stake transactions strategically before and after reward distribution, leading to substantial gains through front-running and validator_shares manipulation.
Code Snippet
https://github.com/sherlock-audit/2023-11-covalent/blob/main/cqt-staking/contracts/OperationalStaking.sol#L163-L170
https://github.com/sherlock-audit/2023-11-covalent/blob/main/cqt-staking/contracts/OperationalStaking.sol#L262-L320
https://github.com/sherlock-audit/2023-11-covalent/blob/main/cqt-staking/contracts/OperationalStaking.sol#L400-L402
https://github.com/sherlock-audit/2023-11-covalent/blob/main/cqt-staking/contracts/OperationalStaking.sol#L458-L461
https://github.com/sherlock-audit/2023-11-covalent/blob/main/cqt-staking/contracts/OperationalStaking.sol#L584-L587
Tool used
Manual Review
Recommendation
Don't allow
stakes
for a block or two before/after calling rewardValidators.Duplicate of #47