Trick or Treat

First Flight #27
Beginner FriendlyFoundry
100 EXP
View results
Submission Details
Severity: high
Invalid

Global nextTokenId Vulnerability in SpookySwap Allows Treat Mismatch Exploit

Summary

In the SpookySwap contract, the nextTokenId identifier is used globally across all treat purchases. This creates a vulnerability where a user could initiate a purchase of a lower-cost treat but potentially receive an NFT representing a higher-cost treat by manipulating the treat selection. This can lead to a mismatch between the treat paid for and the treat received.

Vulnerability Details

The contract increments the nextTokenId variable each time an NFT is minted, regardless of the treat type. Since the token ID is shared across all treats, a user could first book a low-cost treat and, by calling functions in quick succession or taking advantage of asynchronous processing, potentially end up receiving a higher-cost treat instead.

Steps to Reproduce:

  1. A user initiates a transaction for a lower-cost treat, resulting in nextTokenId incrementing.

  2. Before finalizing the treat type, the user could potentially re-trigger a treat function (e.g., by calling trickOrTreat again with a different treat name).

  3. If timed correctly, the user may receive a more expensive treat than what was initially paid for, creating an imbalance in value distribution.

Impact

This vulnerability could allow users to acquire higher-value treats while only paying for lower-cost ones. This results in revenue loss for the contract owner and may lead to inventory misallocation.

Tools Used

  • Tests

Recommendations

  1. Separate Token ID Tracking for Each Treat: Implement individual nextTokenId tracking per treat to ensure unique token IDs are incremented based on each specific treat type rather than globally.

  2. Explicit Treat Mapping in Minting Function: Add a mapping between token IDs and specific treat types at the time of minting. For instance, include a check in the mintTreat function to verify that the treat minted corresponds to the treat paid for by the user.

These changes would ensure users can only acquire the treats they specifically paid for, preventing any potential mismatch or value imbalance between treat types.

Updates

Appeal created

bube Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.