The reentrancy vulnerability in mint in nextgencore can allow an attacker to mint more tokens than they are allowed to #1076
Labels
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
duplicate-1517
edited-by-warden
satisfactory
satisfies C4 submission criteria; eligible for awards
Lines of code
https://github.com/code-423n4/2023-10-nextgen/blob/08a56bacd286ee52433670f3bb73a0e4a4525dd4/smart-contracts/NextGenCore.sol#L189-L200
Vulnerability details
Lines Of Code
https://github.com/code-423n4/2023-10-nextgen/blob/08a56bacd286ee52433670f3bb73a0e4a4525dd4/smart-contracts/NextGenCore.sol#L189-L200
Vulnerability details
Bug Description
The
mint()
function allows for minting new tokens when called by the minter contract and updates the value of how much each address has minted and it does so both in the public and in the allowlist phase but updates different arrays for each phase. To mint a new token it calls the_mintProcessing
internal function which uses safemint to mint a new token but only after calling it do we update the number of tokens minted for the minting address.NextGenCore.sol#L192-L199.
If we look we see that values from both
tokensMintedAllowlistAddress
andtokensMintedPerAddress
are being used in themint()
of the minter contract to check that no one mints more than their max allowance.MinterContract.sol#L213.
MinterContract.sol#L217.
MinterContract.sol#L224.
incrementing those values after calling
_mintProcessing
can cause a reentrancy and because they are used to check that someone does not mint more than his allowance, someone might exploit the reentrancy and use a contract with onERC721Received which will recall themint()
of the minter contract back just after they receive the mint nft to mint a new one which will make it possible for them to mint more nfts then they are allowed to because the values are not updated yet.Impact
A user will be able to use this exploit to mint more tokens than he is allowed to and this is especially dangerous in the allowlist phase since the attacker might mint any number of nfts he wants at the expense of the allowances of others and sell them for a profit.
Proof of Concept
The following Foundry test demonstrates an example of how an attacker can exploit the reentrancy to mint 50 tokens while his allowance is just 1 token:
We use a MockRandomizer for the test that doesnt matter that much and the importante thing is that when excuting the attack we set how many tokens we want to get minted by using the counter variable if we dont do soo we will run into an infinite loop that will end with an eroor so we specify that we want to mint 50 tokens and if anyone want to see the code used to create the merkle root and proof here is it:
Tools Used
Manual Review
Recommended Mitigation Steps
Consider moving the call to the
_mintProcessing
function below after the variable updating like this:Or consider using the openzeppelin ReentrancyGuard
nonReentrant
modifier like this :Assessed type
Reentrancy
The text was updated successfully, but these errors were encountered: