Author: nick

  • Call Injection.

    An unverified contract on Base was exploited, root cause is improper input check. It seems that this function is used for token exchange, but as there’s no check about input for external call, this can be used for call injection. Hacker took fund from users who approved to this contract, gained $125k.

  • AST token hacked.

    AST token on BSC was hacked because of wrong transfer logic. When remove liquidity from pancake pair, AST token decreases pancake pair balance and burn tokens of pancake pair, not increase user’s balance. This means AST token balance of pancake pair decreased 2 times. Hacker exchanged a huge amount of USDT to AST, small amount…

  • BIGO token exploit.

    BIGO token was hacked, root cause is auto burn functionality. In “transfer” function, “_autoBurn” function that decreases pancake pair balance is called. “burnAmount” can be set by sending a few ETH to BIGO token. Hacker exchanged a huge amount of DOGE to BIGO and set “burnAmount”, then called “transfer”. After that he exchanged all BIGO…

  • Unilend hacked.

    Unilend Pool lost $200k. Root cause is wrong health factor check. In “redeemUnderlying” function, LP tokens are burnt, and then health factor is checked. After that collateral tokens are transferred to user. When checking health factor, user token balance is calculated using current balance of token in pool contract, and as tokens are not transferred…

  • Sandwich attack!

    A contract named “FortuneWheel” was exploited due to public swap functionality. “swapProfitFees” function exchanges tokens using pancakeswap and has no modifier. Hacker exchanged a huge amount of WBNB to LINK, then called this function, exchanged LINK to WBNB again. He gained almost $21k. There should be access check in “swapProfitFees” function.

  • Mosca hacked.

    Mosca on BSC was hacked because of wrong balance calculation. As you can see in picture, withdraw balance is calculated by user.balance + user.balanceUSDT + user.balanceUSDC. But after “withdrawAll()”, only user.balance is set 0, USDT and USDC balance not changed, this means anyone can withdraw tokens several times if USDT or USDC balance is not…

  • Sorra staking hacked.

    Sorra staking contract was hacked because of wrong reward calculation. When user withdraws his tokens, they get reward. “userRewardsDistributed” value is increased when user gets reward, but this value is not considered when calculating pending reward, this means users can get reward several times. Hacker just called “withdraw(1 wei)” multiple times, gained almost $43k.

  • LAURA token exploit.

    LAURA token has “removeLiquidityWhenKIncreases” function that decreases uniswap pair balance is K is increased. Hacker exchanged a huge amount of WETH to LAURA and added some of LAURA and WETH to to uniswap pair to increase K, then called “removeLiquidityWhenKIncreases()” function. After that he exchanged all LAURA to WETH, as x*y=k got much smaller, he…

  • BIZNESS hacked.

    BIZNESS on base was hacked, root cause is reentrancy. Locker contract has “splitLock” function that splits lock position. In this function, “_feeHandler()” function is used for sending fees to treasury and remaining to user. There’s no reentrancy check in “splitLock” function, and locked amount is decreased after “_feeHandler()” is called. This can be used for…