Root + Impact

Description

This problem comes from the yul implementation of _burn which subtracts value from both _totalSupply and the target account balance with raw sub and zero validation.

Risk

An attacker simply calls it with a value greater than their actual balance (even with zero balance). The unchecked sub wraps around, raising both supply and the caller’s balance to near 2^256. Because the revert is never triggered, _burn emits no event and silently grants the attacker as many tokens as they want.

Impact

An attacker can mint ≈2^256 tokens, drain all liquidity pools, or break any accounting that assumes totalSupply() equals the sum of balances. This is a critical protocol takeover risk with no preconditions besides access to a burn path.

Proof of Concept

1. Deploy any ERC‑20 that inherits this ERC20 implementation; ensure it exposes a callable burn path (e.g., burn(uint256 value) or burn(address,uint256) that forwards to _burn).

2. The burn entry point forwards these parameters straight into _burn(account,value); no checks are performed before entering the yul routine.

3. Inside _burn, sstore(supplySlot, sub(supply, value)) executes first, so _totalSupply underflows and becomes type(uint256).max - value + supply, which equals type(uint256).max when supply was zero, effectively minting the attacker’s desired supply.

4. Attacker immediately calls transfer to move the forged balance into an exchange or liquidity pool and cashes out.

Recommended Mitigation

Before each subtraction in _burn, ensure value is not greater than the respective stored amount: load balance and supply, revert with ERC20InsufficientBalance/custom error if value > accountBalance or value > supply. Alternatively, implement _burn in Solidity so built-in checked arithmetic reverts on underflow.