An attacker can front-run the burn() function if the amount passed as an argument is substantial, and then back-run the transaction to call distributeFees() in the LiquidationPoolManager.
Bob, Alice, and John are borrowers. They have minted 500,000 euros, 1,000,000 euros, and 500,000 euros, respectively. Each of them burns their euros simultaneously. Considering the current burn fee is 0.5%, and the total amount burned is 2,000,000 euros, the quantity sent to the LiquidationPoolManager will be 10,000 euros. A malicious actor could front-run the euro transfers and call the increasePosition() function in the LiquidationPool.
He can then back-run these transactions by calling distributeFees() in the LiquidationPoolManager to collect fees. The malicious actor only needs to wait for a day to receive the fees from the burns.
The issue here is that the LiquidationPool distribute fees to all the TST holders and not only the ones that have a position.
A malicious actor can take a part of the fees without taking any risk and take a part of the TST holders' fees without taking any risk.
Manual review
Refactor in the Liquidation Pool the distributeFees() and getTstTotal()(L55-L62)
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.