re-entrency possible on processWithdraw since external call is made before burning user's shares in Vault
Since the function is only accessible by keeper (likely a router), which from the example of the mockRouter, would bundle the withdraw and "afterWithdrawalExecution" together. However since the router is out-of-scope, and there is still a possible chance that the user can make use of the router to re-enter into the function (without re-entrency lock), and be able to drain more fund that he actually deserves. This is submitted as a medium risk.
drain of user funds.
burn user's share first, before executing external call at the end.
Impact: High Likelihood: Low The only possible external caller is the keepers. But this is still a vulnerability and it is strongly recommended to implement CEI pattern. Given the limited impact, similar issues (reentrancy by keepers) are grouped.
Impact: High Likelihood: Low The only possible external caller is the keepers. But this is still a vulnerability and it is strongly recommended to implement CEI pattern. Given the limited impact, similar issues (reentrancy by keepers) are grouped.
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.