BeatToken.burnFrom calls _burn(from, amount) (BeatToken.sol:24-27) after only checking that the caller is the festival contract. It never verifies that from approved the burn, so the standard ERC20 burnFrom allowance semantics are silently violated. It is safe only by accident: the sole current caller, FestivalPass.redeemMemorabilia (FestivalPass.sol:197), always passes msg.sender as from.
Likelihood:
Low. Exploitation requires the festival contract to be upgraded or extended with a new code path that passes an arbitrary from. Today's only caller is self-referential, so no live attack exists.
Impact:
Low. As written there is no loss, but the function is a latent footgun: any future FestivalPass function that calls burnFrom(victim, amount) would burn a victim's BEAT with zero consent, since the privileged-caller check is the only gate. A function named burnFrom that ignores allowances will mislead future maintainers into assuming standard, consent-based behavior.
If a future festival path forwards a non-caller from, a victim's balance is burned without approval.
Enforce an allowance (use ERC20 _spendAllowance) or rename to make the privileged, self-burn intent explicit.
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.