The addNewBatch function in the RAACNFT contract allows the owner to increment currentBatchSize without an upper bound, potentially enabling an excessively large batch size that could disrupt minting operations or exceed practical limits (e.g., gas constraints, NFT ID space). This fully valid medium-impact, medium-likelihood vulnerability could lead to operational inefficiencies, unintended NFT supply inflation, or system instability, as there’s no cap to prevent abuse or error by the owner.
The addNewBatch function increases currentBatchSize without restrictions beyond a zero check:
currentBatchSize is a uint256 with no maximum limit enforced.
An owner could mistakenly or maliciously set _batchSize to an extreme value (e.g., 2^256 - 1), causing currentBatchSize to approach or exceed reasonable operational bounds.
While mint uses _tokenId directly (not tied to currentBatchSize for validation), an unbounded currentBatchSize implies an intended supply cap that isn’t enforced, risking confusion or abuse in downstream systems expecting a controlled batch size.
Scenario:
Owner calls addNewBatch(1e18) repeatedly, inflating currentBatchSize to 1 quintillion.
Users mint NFTs, depleting practical token ID space (e.g., if tied to house prices via raac_hp).
Gas costs for minting or tracking escalate, or system assumes infinite supply, destabilizing $10M in NFT-backed value.
No revert occurs until overflow (post-Solidity 0.8), but practical limits (e.g., oracle data) are exceeded.
Analysis: The lack of a cap is a clear oversight, as batch size increases should align with protocol capacity (e.g., house price data availability), making this a design flaw with operational consequences.
The potential disruption of minting operations or inflation of perceived NFT supply (e.g., affecting $10M in NFT value) constitutes a medium-impact issue, as it doesn’t directly drain funds but could degrade system reliability, increase gas costs, or mislead users about available NFTs. The medium likelihood reflects the owner’s ability to call addNewBatch at will, with a realistic chance of error or misuse (e.g., fat-finger input), especially in a protocol managing significant value.
Manual Code Review: Confirmed no upper limit exists beyond the uint256 max, and currentBatchSize’s role lacks enforcement in mint, exposing a gap in supply control logic.
Add an upper limit to currentBatchSize to enforce a reasonable batch size:
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.