The configurePass function allows the organizer to reset the passSupply to 0 at any time, even after passes have already been minted and distributed.
This does not burn or revoke already minted passes from users.
As a result, the actual number of passes in circulation (tracked by ERC1155 balances) will be out of sync with the passSupply variable.
Likelihood: Medium
Supply Mismatch: The passSupply variable will no longer reflect the true number of passes in existence.
Potential Over-Minting: The organizer could set a new maxSupply and passSupply, allowing more passes to be minted than originally intended.
Loss of Integrity: The contract’s internal accounting becomes unreliable, which can lead to trust and operational issues.
Example Scenario
100 VIP passes are minted (passSupply[2] == 100).
Organizer calls configurePass(2, newPrice, 200), which resets passSupply[2] to 0.
The contract now thinks 0 VIP passes exist, but in reality, 100 are already in circulation.
Up to 200 more VIP passes could be minted, resulting in 300 total, far exceeding the intended cap.
Never reset passSupply in configurePass.
This is not acceptable as high because any attack vectors related to organizer trying to milk ETH from participants is voided by the fact that the organizer is trusted.
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.