TheNFTV2 Stale Burn Approval

The verified ABI for the deployed LAND contract shows _burn(address from, address owner, uint256 id) as a public function. The contract also contains intended authorization wrappers such as burn(uint256) and burnFrom(address,uint256), which strongly indicates _burn should have remained an internal helper or should have enforced the same authorization rules itself. Instead, the deployed contract left a direct external path into destructive ownership state mutation.

3. Vulnerability Analysis & Root Cause Summary

This incident is an access control failure in a critical ownership-destruction path. The core invariant for an NFT contract is that only the token owner or an explicitly authorized operator may burn a token. The LAND implementation breaks that invariant because _burn authenticates caller-supplied identity parameters instead of authenticating msg.sender.

The vulnerable function is:

function _burn(address from, address owner, uint256 id) public {
    require(from == owner, "not owner");
    _owners[id] = 2**160; // cannot mint it again
    _numNFTPerAddress[from]--;
    emit Transfer(from, address(0), id);
}

That code mutates ownership state, decrements the holder balance, and emits the burn event without checking whether msg.sender is the owner, an approved operator, a super operator, or an admin. By contrast, burnFrom does perform those checks before delegating to _burn. The exploit therefore did not require bypassing cryptography, stealing keys, or obtaining approval; it only required reading the public owner address and calling the wrong entrypoint.

4. Detailed Root Cause Analysis

The end-to-end exploit path is deterministic. First, the attacker identifies an existing token and reads its current owner from public state. The relevant ownership code path confirms this information is publicly derivable:

function _ownerOf(uint256 id) internal view returns (address) {
    require(id & LAYER == 0, "Invalid token id");
    uint256 owner1x1 = _owners[id];

    if (owner1x1 != 0) {
        return address(owner1x1);
    }
    ...
}

Second, the attacker submits a direct transaction to the LAND contract calling selector 0x6ee678ae, which decodes to _burn(address,address,uint256). The transaction metadata shows the direct call target and calldata:

from  = 0x6fb0b915d0e10c3b2ae42a5dd879c3d995377a2c
to    = 0x50f5474724e0ee42d9a4e711ccfb275809fd6d4a
input = 0x6ee678ae
        0000000000000000000000009cfa73b8d300ec5bf204e4de4a58e5ee6b7dc93c
        0000000000000000000000009cfa73b8d300ec5bf204e4de4a58e5ee6b7dc93c
        0000000000000000000000000000000000000000000000000000000000000e9a

Those two address words are identical and equal to the real owner of token 3738, so the only gate in _burn passes. The seed execution trace then shows the exact unauthorized burn and its post-state effects:

Land::_burn(0x9cfA73B8d300Ec5Bf204e4de4A58e5ee6B7dC93C, 0x9cfA73B8d300Ec5Bf204e4de4A58e5ee6B7dC93C, 3738)
  emit Transfer(_from: 0x9cfA73B8d300Ec5Bf204e4de4A58e5ee6B7dC93C, _to: 0x0000000000000000000000000000000000000000, _tokenId: 3738)
  storage changes:
    victim LAND balance: 2762 -> 2761
    token owner slot:    0 -> 0x0000000000000000000000010000000000000000000000000000000000000000

That post-state is consistent with the success predicate in the root cause analysis: the victim loses one LAND token, the token is marked as burned, and future ownerOf(3738) calls revert with token does not exist. No additional privilege, prior approval, or helper contract is required. This makes the incident a permissionless ACT opportunity rather than a privileged misuse case.

5. Adversary Flow Analysis

The attacker flow is a single direct transaction.

1. Observe that token 3738 exists and is owned by 0x9cfa73b8d300ec5bf204e4de4a58e5ee6b7dc93c.
2. Submit transaction 0x34516ee081c221d8576939f68aee71e002dd5557180d45194209d6692241f7b1 to LAND contract 0x50f5474724e0ee42d9a4e711ccfb275809fd6d4a.
3. Call _burn(victimOwner, victimOwner, 3738) directly, bypassing the intended burnFrom authorization path.
4. LAND emits Transfer(victimOwner, address(0), 3738), decrements the victim balance from 2762 to 2761, and records the token as burned.
5. Subsequent ownerOf(3738) queries revert, proving the destruction is final.

The important decision point is that the attacker does not try to satisfy the real authorization logic in burnFrom. Instead, the attacker uses the externally exposed helper and supplies matching calldata values, which is enough to satisfy the flawed check.

6. Impact & Losses

The measurable loss is the permanent destruction of one LAND NFT, token 3738, owned by 0x9cfa73b8d300ec5bf204e4de4a58e5ee6b7dc93c. In raw token accounting terms, the victim's balance dropped from 2762 to 2761, and the token became non-existent after the transaction.

This is a non-monetary but concrete integrity failure. The exploit breaks NFT ownership guarantees for every token in the collection because any existing token whose owner is publicly known can be burned by an arbitrary unprivileged caller through the same entrypoint.

7. References

1. Exploit transaction: 0x34516ee081c221d8576939f68aee71e002dd5557180d45194209d6692241f7b1
2. LAND contract: 0x50f5474724e0ee42d9a4e711ccfb275809fd6d4a
3. Verified ABI showing public _burn(address,address,uint256)
4. Verified ERC721BaseToken.sol implementation of _burn and burnFrom
5. Verified LandBaseToken.sol ownership resolution path used by ownerOf
6. Seed execution trace showing _burn, the Transfer event, and storage changes
7. Validator challenge result confirming the root cause analysis passes strict review