MoltenSwap Rug Pull

Steps 1 to 4 describe what the verified code allows; step 5 is what the De.Fi listing reports.

1. Users stake LP tokens in the MasterChef: deposit pulls them in with pool.lpToken.safeTransferFrom(address(msg.sender), address(this), _amount); and records only a number in user.amount. The staked LP tokens sit in the MasterChef's own balance.
2. The owner-only set() is documented as updating a pool's allocation points and deposit fee, but its last lines read: uint256 bal = lpToken.balanceOf(address(this)); ... lpToken.safeApprove(address(feeAddress), bal); and pool.lpToken.safeTransfer(address(feeAddress), bal);. A call that gets through sends the pool's whole LP balance to feeAddress, whatever values are passed for _allocPoint and _depositFeeBP.
3. There is a limit on repeating this. safeApprove in the SafeBEP20 library contains require((value == 0) || (token.allowance(address(this), spender) == 0), "SafeBEP20: approve from non-zero to non-zero allowance");, and the MasterChef's safeTransfer to feeAddress does not spend the allowance it just set. So after one call with a positive balance, another set() on the same LP token reverts while that allowance is unspent, unless a call made when the pool's balance is zero resets it (or feeAddress spends it). Later deposits into that pool can therefore be swept only after such a reset. Pools with different LP tokens are unaffected by each other's allowance.
4. Users' recorded balances are not reduced. withdraw and emergencyWithdraw still pay out of the contract's own LP balance (pool.lpToken.safeTransfer(address(msg.sender), amount);), which stays empty after a sweep unless tokens are returned. The deposit-fee check also permits up to 100%: require(_depositFeeBP <= 10000, ...). setFeeAddress can only be called by the current feeAddress, so the destination is controlled by whoever holds that address.
5. Reported: De.Fi says the deployer invoked set() multiple times, that calling set() led to an LP-token transfer to an external wallet, and that the wallet removed the liquidity in nine transactions listed above. The loss figure is $121,994.