Token-0x
First Flight #54
Beginner FriendlyDeFi
100 EXP
View all submissions
Previous Next
Submission Details
Impact: high
Likelihood: high

Unchecked `burn` Allows Arbitrary Balance and `totalSupply` Manipulation

Author Revealed upon completion

Description:
The internal _burn implementation in ERC20Internals performs unchecked subtraction on both totalSupply and the account balance, without verifying that the account has enough tokens or that totalSupply is large enough. It uses raw Yul sub without any underflow checks:

function _burn(address account, uint256 value) internal {
assembly ("memory-safe") {
// ...
let supply := sload(supplySlot)
sstore(supplySlot, sub(supply, value)) // No underflow check
// ...
sstore(accountBalanceSlot, sub(accountBalance, value)) // No underflow check
}
}

Any caller can therefore burn an arbitrary value from any account, even if that account’s balance (and global totalSupply) is much smaller than value. Because the subtractions are unchecked, they underflow and wrap modulo 2^256, effectively creating enormous balances and totalSupply values.

Impact:

  • A malicious user can:

    • Underflow another user’s balance, turning a small balance into 2^256 - 1 tokens.

    • Underflow totalSupply, breaking all supply‑based invariants and likely any DeFi integrations relying on it.

  • If the token is used in DeFi protocols (AMMs, lending, gauges), this can be used to:

    • Drain pools by transferring the artificially inflated balance.

    • Break assumptions about totalSupply (e.g. share price calculations, reward distributions), potentially leading to further downstream loss of funds.

  • Even if a specific derived token intends to restrict access to _burn, the base implementation is unsafe “by default” and is therefore very easy to misuse (as demonstrated by the sample Token).

Overall this is critical when _burn is exposed directly or indirectly to untrusted users, and still high‑risk even when only “trusted” code calls it, because a single missing check in future extensions leads to catastrophic consequences.

Proof of Concept:

Token using Token-0x ERC20:

// Add this test to Token.t.sol
​
function test_burnUnderflowCreatesHugeBalanceAndSupply() public {
// Arrange: mint a small amount to Alice
address alice = makeAddr("alice");
uint256 initialAmount = 1e18;
token.mint(alice, initialAmount);
​
assertEq(token.balanceOf(alice), initialAmount);
assertEq(token.totalSupply(), initialAmount);
​
// Act: burn *more* than Alice's balance from Alice
// This should revert in a correct ERC20, but Token-0x does not check.
uint256 burnAmount = initialAmount + 1;
​
// No expectRevert here - we expect the call to succeed!
token.burn(alice, burnAmount);
​
// Assert: balance and totalSupply have underflowed to 2^256 - 1
uint256 newBalance = token.balanceOf(alice);
uint256 newSupply = token.totalSupply();
​
assertEq(newBalance, type(uint256).max, "balance underflowed to max");
assertEq(newSupply, type(uint256).max, "totalSupply underflowed to max");
}

Token2 using OpenZeppelin ERC20:

// Add this test to Token2.t.sol
​
function test_burnUnderflowReverts_OZ() public {
// Arrange: mint a small amount to Alice using the OZ-based token
address alice = makeAddr("alice");
uint256 initialAmount = 1e18;
token.mint(alice, initialAmount);
​
assertEq(token.balanceOf(alice), initialAmount);
assertEq(token.totalSupply(), initialAmount);
​
// Act & Assert: burning more than balance should revert in OpenZeppelin
uint256 burnAmount = initialAmount + 1;
​
vm.expectRevert();
token.burn(alice, burnAmount);
}

Running these tests shows:

  • Token-0x Token does not revert and instead sets both balanceOf(alice) and totalSupply() to 2^256 - 1.

  • OpenZeppelin’s Token2 correctly reverts the transaction.

Mitigation:

  • Add explicit checks in _burn before performing the subtractions:

function _burn(address account, uint256 value) internal {
assembly ("memory-safe") {
if iszero(account) {
mstore(0x00, shl(224, 0x96c6fd1e))
mstore(add(0x00, 4), account)
revert(0x00, 0x24)
}
​
let ptr := mload(0x40)
let balanceSlot := _balances.slot
let supplySlot := _totalSupply.slot
​
let supply := sload(supplySlot)
+ if lt(supply, value) {
+ // Either introduce a dedicated error or reuse ERC20InsufficientBalance
+ mstore(0x00, shl(224, 0xe450d38c))
+ mstore(add(0x00, 4), account)
+ mstore(add(0x00, 0x24), supply)
+ mstore(add(0x00, 0x44), value)
+ revert(0x00, 0x64)
+ }
sstore(supplySlot, sub(supply, value))
​
mstore(ptr, account)
mstore(add(ptr, 0x20), balanceSlot)
​
let accountBalanceSlot := keccak256(ptr, 0x40)
let accountBalance := sload(accountBalanceSlot)
+ if lt(accountBalance, value) {
+ mstore(0x00, shl(224, 0xe450d38c)) // ERC20InsufficientBalance
+ mstore(add(0x00, 4), account)
+ mstore(add(0x00, 0x24), accountBalance)
+ mstore(add(0x00, 0x44), value)
+ revert(0x00, 0x64)
+ }
sstore(accountBalanceSlot, sub(accountBalance, value))
}
}

  • Alternatively, implement _burn in Solidity with default checked arithmetic and only use assembly for storage slot derivation.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!