Root + Impact

Critical

Integer Underflow Vulnerability in _burn()

Description

The contract’s _burn() function is implemented in low‑level inline assembly (Yul). in the following code

This line reads the user’s current balance from storage and then writes back the result of accountBalance – value without any check that accountBalance >= value. Because it uses raw Yul arithmetic (via sub()) and direct storage mutation (sstore), there is no underflow protection, even though the contract is compiled under Solidity 0.8.x. Inline assembly bypasses Solidity’s built-in overflow/underflow checks.

As a result, if value (the burn amount) is larger than the current balance, the subtraction operation wraps around modulo 22562^{256}2256, producing a very large “underflowed” balance — rather than reverting or failing. This violates fundamental token invariants (balances ≥ 0, correct total supply) and leads to a severe security issue.

Risk

• Fake token creation / unlimited minting

Because the underflow causes the balance to wrap around to a very large uint256 (near 2256−12^{256} - 12256−1), an attacker who triggers the bug can magically get a huge token balance — basically “out of thin air.” This means:

• They now hold vastly more tokens than they ever earned or were issued.

• The “total supply” and other supply/tracking invariants are broken.

• The attacker can then transfer or sell these tokens, draining value from the system or other holders.

• value dilution

If many users (or the attacker) exploit the underflow bug:

• The token’s supply skyrockets artificially (or becomes inconsistent).

• What remains of the “legitimately” issued tokens become worthless (inflation / dilution).

• Trust collapses — tokenomics fail, holders lose value, the project may collapse.

This undermines any economic or financial logic built on the token (staking, governance, dividends, e

Likelihood:

• Very High because user has access to _burn fucntion

Impact:

• Critical

Proof of Concept

Recommended Mitigation