Root + Impact

Description

• Describe the normal behavior in one or more sentences

Redeeming memorabilia should follow a safe pattern: internal state updates first, then external calls. In this implementation, an external call to burnFrom() on the BeatToken contract is made before any internal mint logic, and there is no nonReentrant modifier in place.

• Explain the specific issue or problem in one or more sentences

This breaks the checks effects interactions pattern, exposing the function to potential reentrancy issues if burnFrom() is hooked (e.g., via a malicious BeatToken implementation).

Risk

Likelihood:

• Reason 1 // Describe WHEN this will occur (avoid using "if" statements)

Occurs whenever redeemMemorabilia() is called.

• Reason 2

Reentrancy becomes exploitable if BeatToken is malicious, upgradable, or if control over it is gained.

Impact:

• Impact 1

Can result in multiple redemptions with the same token balance.

• Impact 2

Potentially allows unauthorized minting, DoS via unexpected flow, or draining of collectibles.

Proof of Concept

Assume BeatToken.burnFrom() contains a callback to redeemMemorabilia()

Reentrancy allows redeemMemorabilia() to be called again before mint finishes, enabling multiple redemptions per burn.

Recommended Mitigation

The redeemMemorabilia() function performs an external call to burnFrom() before completing internal logic. If the external contract (e.g. a malicious BEAT token) contains reentrant code, it could re-enter the function and exploit the contract’s state. This makes the function vulnerable to reentrancy.