Vulnerability Details

1. Centralized Control of gameContract

Bug Description

The EggstravaganzaNFT contract introduces a central point of control through the gameContract state variable, which determines which external contract is authorized to mint new NFTs. This value is set by the setGameContract function:

This function is restricted to the contract owner via the onlyOwner modifier, granting the owner unilateral power to change the gameContract address at any time. While ownership-based access control is a standard pattern, it introduces a significant centralization risk in this case because the gameContract is the sole authorized minter of NFTs.

If the owner account is compromised or malicious, it can set the gameContract to any arbitrary contract, including one under the attacker’s control. This malicious contract could then call the mintEgg() function repeatedly and mint an unbounded number of NFTs to any address, undermining the scarcity and integrity of the Eggstravaganza NFT collection.

Moreover, even without compromise, this centralized power violates core decentralized trust assumptions—users must trust the owner’s key security, benevolence, and long-term alignment with the system’s goals.

Impact

• Unlimited Unauthorized Minting: An attacker with control over the owner account can update the gameContract to any malicious contract that abuses the mintEgg() function to mint unlimited NFTs. This would dilute the value of existing tokens and ruin the integrity of the NFT collection.

• Loss of Trust and Decentralization: A Centralized minting authority significantly reduces trust in the platform. Users may lose confidence in the NFT’s fairness and scarcity if minting rights are not transparently governed.

• Economic Exploitation: If the NFTs hold value or utility in a larger ecosystem (e.g., in-game use, staking, or trading), this vulnerability could be exploited to gain unfair economic advantage, devalue assets, or disrupt downstream platforms that integrate with this collection.

• Security Critical Dependence on Owner Key: The security of the entire minting process becomes tightly coupled with the private key management of a single owner account. Any mistake, loss, or compromise has immediate and severe consequences.

Tools Used

• Manual Review

Recommended Mitigation Steps

1. Immutable Game Contract (If Possible):

   • If the use case allows, set the gameContract only once during deployment and do not allow updates. This removes the possibility of malicious reassignment altogether.

   constructor(string memory _name, string memory _symbol, address _gameContract)

   ERC721(_name, _symbol) Ownable(msg.sender)

   {

   require(_gameContract != address(0), "Invalid game contract");

   gameContract = _gameContract;

   }

   ​

   • Remove the setGameContract() function entirely.

2. Decentralized Access Control:

   • If dynamic updates are necessary, use a DAO, multisig, or time-lock mechanism (e.g., OpenZeppelin’s TimelockController) to gate the setGameContract() function.

   • This ensures that changes require multiple parties' consent or allow the community to audit upcoming changes before they take effect.

3. Event Logging and Monitoring:

   • Emit detailed events when the gameContract is updated.

   • Consider integrating with on-chain monitoring systems that alert stakeholders when critical roles are changed.

   event GameContractUpdated(address indexed oldAddress, address indexed newAddress);

   ​

4. Contract Pausability:

   • Introduce a pause() Mechanism to temporarily disable minting in the event of suspicious behavior, giving time to react before further damage is done.

By applying these mitigations, the contract’s minting mechanism becomes more secure, trust-minimized, and aligned with best practices in decentralized systems.