Audit-grade security at the speed of deployment.Audit-grade security at the speed of deployment.

Reentrant withdrawal drains ETH before credit is reduced

      require(msg.sender.call.value(amount)());
      credit[msg.sender]-=amount;

withdraw sends ETH to msg.sender via a low-level call at line 17 before reducing credit[msg.sender] at line 18. A malicious recipient contract can use its fallback function to reenter withdraw repeatedly while its recorded credit remains unchanged, receiving multiple withdrawals against the same credit. This can drain ETH deposited for other users.

Fix: Apply checks-effects-interactions: reduce credit[msg.sender] before making the external call.

benchmark case swc-simple-dao, SWC registry

Anyone can drain all vault-held tokens through emergencyWithdraw

    function emergencyWithdraw(address token, address to, uint256 amount) external {
        IERC20(token).transfer(to, amount);
    }

emergencyWithdraw has no authorization check. Any caller can select the staking token, reward token, or any other token held by the vault, set themselves as `to`, and transfer the vault's balance to themselves. This permits direct theft of all deposited staking tokens and funded reward tokens.

Fix: Restrict this function to an authorized role, such as `require(msg.sender == owner)`, and consider preventing recovery of the staking and reward tokens while user balances or reward obligations remain outstanding.

tx.origin authorization allows phishing-based withdrawal

        require(tx.origin == owner);

Authorization is based on tx.origin rather than msg.sender. If the owner is induced to call an attacker-controlled contract, that contract can call sendTo with an attacker-selected receiver and amount while tx.origin remains the owner. The contract will then transfer its ETH to the attacker-controlled receiver.

Fix: Authenticate the direct caller instead: require(msg.sender == owner).

benchmark case swc-tx-origin, SWC registry