“transferFee” function has really basic vulnerability. who made this router?

Root cause is old oracle that hasn’t updated for a long time. In hacking, he transferred some tokens into cToken because of borrow rate.

Victim contract doesn’t check if msg.sender is valid in “uniswapV3Callback” function.

Root cause is in “burn()” function. “burn()” function decreases balance of uniswap pair. To bypass first line, he bought 1 wei of token hundreds of time, and then called “burn()” function. Hacker gained $900. 😁

Root cause is in price calcualtion. As you can see, price is calculated by amount of tokens in LP, but this can be maniupulated easily. Hacker could manipulate this price by transfering tokens into LP,after that he used “skim” to get tokens.

There’s no reenctrance check in code.

There was vulnerability in repay adapter contract. In swapAndRepay function, it approves tokens to Paraswap router. But if swap is not performed using approved token, allowance is not decreased. Using this hacker let victim contract approve tokens to paraswap router, and then moved those tokens to himself. If you want more detail, dm me or…

I think root cause is improper check of calldata in “uniswapV2Call” function. It needs to check first parameter-sender address, but it didn’t. Hacker could call this callback function by calling “swap” function.

Anyone who holds SPythia token can call “claimRewards” function without any locking period. Hacker could call “claimRewards” function several times by moving tokens from one account to another account. Reward amout should be calculated using locked period.