Root + Impact

Description

• Normally, LINK consumption should be protected with checks to avoid draining the balance.

• Here, the contract allows continuous Chainlink Function requests via repeated performUpkeep() calls or by registering with an extremely low deposit and zero heartbeat, triggering infinite upkeep.

Risk

Likelihood:

• Will occur as soon as a malicious user interacts with low LINK deposits or calls performUpkeep() on many tokenIds.

• No LINK threshold, rate-limit, or gas refund check exists to prevent abuse.

Impact:

• LINK funds drained rapidly, making automation and Chainlink Functions unusable.

• Service degradation for all users and blocked automation due to insufficient LINK.

Proof of Concept

Here's a scenario:

1. Attacker calls requestMintWeatherNFT(..., false, 0, 0) multiple times, minting NFTs without depositing LINK.

2. Then, attacker repeatedly calls performUpkeep() for each token, forcing the contract to send LINK-consuming Chainlink Function requests in a tight loop.

3. Over time, LINK is drained, and the contract can no longer serve real users.

Recommended Mitigation

• Enforce a non-zero minimum heartbeat value, e.g., require(heartbeat >= MIN_HEARTBEAT).

• Enforce a minimum _initLinkDeposit and validate registration success before accepting the request.

• Consider using pull-payment model or user-funded LINK balance system where each NFT's upkeep and function calls are directly tied to user deposits.

• Add a LINK balance check before sending Chainlink Function requests to prevent unexpected failure.

• Optionally: track and cap LINK usage per user or token to contain abuse.