Normally, the configurePass
function should only be used to set up a pass type before any sales occur, ensuring the maxSupply
is enforced for the lifetime of the pass.
In this implementation, the organizer can call configurePass
at any time, which resets the passSupply[passId]
counter to 0. This allows the organizer to sell more passes than originally intended by reconfiguring the pass mid-sale.
Likelihood:
This will occur if the organizer decides to reconfigure a pass after some have already been sold.
The risk is present in any project where the organizer has ongoing control and there is no restriction on reconfiguration.
Impact:
The organizer can sell more passes than the original maxSupply
, diluting the value of existing passes and breaking user trust.
This can lead to over-selling, user complaints, and reputational damage.
Explanation:
This test demonstrates that the organizer can reset the supply counter and sell more passes than the original maxSupply
, proving the vulnerability.
Add a check to ensure that a pass type can only be configured if no passes of that type have been sold yet.
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.