Normal behavior: _mint should increase _totalSupply by value, increase account's balance by value, and emit the Transfer(address(0), account, value) event. All arithmetic must preserve invariants (no wraparound) and respect access control.
Specific issue: the function performs arithmetic and storage writes in inline assembly using the EVM add opcode. In Solidity ≥0.8 the high-level + operator is checked for overflow, but the raw add opcode used here is unchecked and will silently wrap on overflow. As written, an attacker or privileged minter can choose value such that supply + value or balance + value wraps modulo 2²⁵⁶, defeating the supply/balance invariants and enabling token inflation or logic bypasses that rely on monotonic total supply.
Likelihood:
Requires a call path that executes this internal _mint. If such a call path exists (common in contracts with admin/owner minting), the vulnerability is exploitable.
Impact:
Creation of arbitrarily large effective token supply while observed totalSupply becomes inconsistent (wrap to small value).
Bypass of supply caps, distribution logic, or on-chain checks that rely on totalSupply monotonicity.
In the poc we can clearly see that the earlier balance of the account was uint256.max
When we try to mint even 3 tokens it resets back instead of reverting the call.
Remove raw arithmetic in assembly unless strictly required for gas optimization and proven safe.
Prefer a high-level Solidity implementation that benefits from built-in checked arithmetic (Solidity ≥0.8)
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.
The contest is complete and the rewards are being distributed.