Submitted by oakcobalt, also found by aldarion and seeques
https://github.com/code-423n4/2025-03-silo-finance/blob/0409be5b85d7aabfbbe10de1de1890d4b862d2d5/silo-vaults/contracts/SiloVault.sol#L985
SiloVaults totalSupply() accrueFees from interests (delta totalAssets). Such fee accrual is updated through _accrueFee() which mints an additional share to the fee reciever.
We see that when claiming rewards directly through claimRewards() the accrued extra share is updated first before _claimRewards().
The vulnerability is when _claimRewards() is invoked atomically through hooks (update), the `accrueFee()` will be missed in the users transfer/transferFrom call. In this case, an incorrect totalSupply() will be used for fee accrual, leading to incorrect fee accrual.
Impacts: incorrect and inconsistent reward accrual due to unsynced totalSupply().
In update() hook, consider adding `accrueFee()orupdateLastTotalAssets(accrueFee())before_claimRewards()`.
We see in direct claimRewards flow. totalSupply() will be updated in _accrueFee().
However, the vulnerable flow is transfer/transferFrom -> update(), where `accrueFee()` is missed.
We know transfer/transferFrom flow is vulnerable because unlike deposit/withdraw which calls _accrueFee() first, transfer/transferFrom will directly call _update() without updating totalSupply. This causes an incorrect/inconsistent reward accrual.
IhorSF (Silo Finance) disputed
Silo Finance mitigated:
Status: Mitigation confirmed. Full details in reports from d3e4, t0x1c, and Drynooo.
