The protocol is designed to create and execute a flow fully across multiple transactions before another flow can begin. While the keeper has the ability to cancel a flow, the current implementation does not fully revert all operations upon cancellation. Specifically, it fails to update totalShares after a cancellation, causing it to retain its previous value even after a deposit or withdrawal is canceled.
The vulnerability exists in _cancelFlow:
As shown above, the function cancels a withdrawal or deposit, but it fails to update totalShares, even though it refunds funds to the user and updates totalDepositAmount.
The totalShares value will become inaccurate, leading to inflation. Since the actual shares and totalShares ratio will be corrupted, this could create unintended imbalances within the vault.
Manual review.
Update totalShares accordingly in the cancellation flow.
Likelihood: None/Very Low, when the keeper call cancelFlow after an order execution Impact: High, Inflation/deflation of total shares, and too many fees refunded.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.