The setTreatCost function's zero-cost validation check prevents updating costs for treats initialized at zero value, making these NFTs permanently unclaimable and creating "dead" tokens in the collection.
The TrickOrTreat::setTreatCost function incorrectly requires the existing treat cost to be greater than zero before allowing cost updates, which permanently locks any treat initialized with a zero cost from ever being updated, making these NFTs permanently unclaimable. This vulnerability effectively creates "dead" NFTs in the collection when treats are initially set with zero cost, as the owner cannot update their prices, thus breaking core contract functionality.
Any NFT treat initialized with zero cost becomes permanently unclaimable and unusable, resulting in a permanent loss of functionality for affected tokens and potential revenue loss for the platform.
Foundry Test, Manual Review
To create a test folder and a file named TestTrickOrTreat.t.sol for your Foundry project, you can follow these steps:
Create the test folder: Navigate to your project directory and create a test folder.
Create the TestTrickOrTreat.t.sol file: Inside the test folder, create a file named TestTrickOrTreat.t.sol.
Add the Foundry test code: Here’s an example of what you might include in your TestTrickOrTreat.t.sol file:
Then run the test on your terminal:
To mitigate the issue of ensuring that the treat cost is not set to zero, changing the comparison from > to >= is a sensible approach. This allows the cost to be zero if the intention is to allow free treats or reset the cost.
Here’s how you can modify the function:
The cost of the treat is set only by the owner (in the constructor, in addTreat and in setTreatCost). That means the cost of the treat will always be greater than zero.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.