It's possible to mint more NFTs than _maxAllowance due to lack of re-entrancy protection #43
Labels
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
duplicate-1517
edited-by-warden
partial-50
Incomplete articulation of vulnerability; eligible for partial credit only (50%)
Lines of code
https://github.com/code-423n4/2023-10-nextgen/blob/main/smart-contracts/MinterContract.sol#L196
https://github.com/code-423n4/2023-10-nextgen/blob/main/smart-contracts/NextGenCore.sol#L189
https://github.com/code-423n4/2023-10-nextgen/blob/main/smart-contracts/NextGenCore.sol#L193-L195
Vulnerability details
Impact
Functions
MinterContract.mint()
andNextGenCore.mint()
lack re-entrancy protection. Moreover,NextGenCore.mint()
violates the CEI pattern. As a result it's possible to mint more NFTs than permitted by the_maxAllowance
parameter forMinterContract.mint()
.A user who is eligible for the NFT mint during phase 1 can call
MinterContract.mint()
and present Merkle proof along with other parameters, including_maxAllowance
. The leaf should be in the Merkle tree and incorporatemsg.sender
,_maxAllowance
, and_tokenData
.Furthermore, the user shouldn't mint more than
_maxAllowance
andgencore.retrieveTokensMintedALPerAddress(col, msg.sendert)
holds the number of NFTs minted so far.Eventually,
gencore.mint()
is called.Yet in
gencore.mint()
the value oftokensMintedAllowlistAddress
is updated only aftermintProcessing()
which internally invokes_safeMint()
with a callback. Therefore, a malicious minter could exploit callback from_safeMint()
to callMinterContract.mint()
recursively with the same Merkle proof to mint any number of NFTs, bypassing_maxAllowance
upper bound.Proof of Concept
Tools Used
Manual review.
Recommended Mitigation Steps
Implement re-entrancy protection for
MinterContract.mint()
andNextGenCore.mint()
.Assessed type
Reentrancy
The text was updated successfully, but these errors were encountered: