Fantium — mint delivers the NFT to the caller, not _to

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 28050-undefined-behavior-for-mint-mixbytes-none-fantium-markdown. Standalone Foundry PoC and full write-up: 28050-undefined-behavior-for-mint-mixbytes-none-fantium-markdown_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/access-control/missing-owner-check

Key info#


Protocol	Fantium
Finding	MixBytes, January 2023, AuditVault 28050
Vulnerable code	`FantiumMinterV1.mint` mints to `msg.sender`
Harm	Token 1000000 is owned by the fan. The athlete passed as `_to` owns 0.
Chain	local synthetic (audited Ethereum contracts)

TL;DR#

mint(address _to, ...) is documented as minting to _to. The final mint uses msg.sender. MixBytes paid 100000000000000 wei from the fan, passed the athlete, and ownerOf(1000000) printed the fan. The fix is fantiumNFTContract.mintTo(_to, thisTokenId).

The vulnerable code#

FantiumMinterV1.sol L269. Token id is collectionId * 1_000_000, so collection 1 is token 1000000.

SOLIDITY

function mint(address _to, uint256 collectionId) external payable {
    require(msg.value == PRICE, "price");
    require(_to != address(0), "to");
    uint256 thisTokenId = collectionId * 1_000_000;
    // @> VULN: the final mint is for msg.sender, not _to.
    fantiumNFTContract.mintTo(msg.sender, thisTokenId);
}

Root cause#

_to is checked only for the zero address. It is not the recipient of mintTo. Anyone who calls mint in order to give the token to another address keeps it.

Preconditions#

The caller pays the mint price, 100000000000000 wei. They pass a non-zero _to that is not themselves. Collection 1 has not minted token 1000000 yet.

Attack walkthrough#

The fan pays 100000000000000 wei.
mint is called with the athlete as _to and collection 1.
mintTo is called with msg.sender and token id 1000000.
The price is forwarded to the proceeds address.
ownerOf(1000000) is the fan.
The athlete's balance is 0.
The fan's balance is 1.

Control calls mintTo(_to, thisTokenId). The athlete owns token 1000000. The caller owns 0.

Diagrams#

flowchart TD A["Fan pays the mint price and passes the athlete as _to"] --> B["mint builds token id 1000000"] B --> C["VULN: mintTo is called with msg.sender"] C --> D["ownerOf 1000000 is the fan"] D --> E["Athlete balance is 0"] E --> F["Control mintTo _to gives the athlete the token"]

Impact#

The address named as the owner receives 0 tokens. The caller receives token 1000000 after paying 100000000000000 wei. A mint that was addressed to the athlete does not arrive. The fixed call gives that token to the athlete and leaves the caller at 0.

Remediation#

Replace the recipient with _to: fantiumNFTContract.mintTo(_to, thisTokenId).

How to reproduce#

BASH

cd 28050-undefined-behavior-for-mint-mixbytes-none-fantium-markdown_exp
forge test -vv

Sources#

AuditVault finding: https://github.com/Auditware/AuditVault/blob/main/findings/28050-undefined-behavior-for-mint-mixbytes-none-fantium-markdown.md
MixBytes report: https://github.com/mixbytes/audits_public/blob/master/Fantium/Fantium/README.md
Audited file: contracts/FantiumMinterV1.sol at cb2d97bc30c40321991fe5ab8fc798babba1610f L269

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 28050-undefined-behavior-for-mint-mixbytes-none-fantium-markdown_exp (evm-hack-registry mirror).
AuditVault finding: 28050-undefined-behavior-for-mint-mixbytes-none-fantium-markdown.

Alerts & third-party analyses

Web3Sec X hacked database: search.
Rekt leaderboard: search.
Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.

Source-level debugger — step opcodes and Solidity in sync