The WeatherNft::requestMintWeatherNFT
function allows users to specify the heartbeat
parameter, which determines the frequency of weather update automation for their NFT. However, the contract does not enforce a minimum value for the heartbeat
interval. As a result, users can supply a value of zero or any extremely low value, leading to immediate or extremely frequent automation triggers.
This lack of validation enables anyone to create NFTs with heartbeat intervals that effectively allow continuous or spammed Chainlink Automation requests, rapidly consuming LINK funds and potentially degrading protocol stability for all participants.
The contract does not validate that heartbeat
is greater than zero or above a reasonable minimum threshold.
If a user supplies heartbeat = 0
, the Chainlink Keeper’s checkUpkeep
will always return true
, allowing for immediate and infinite triggers of performUpkeep
.
Users (malicious or otherwise) can exploit this to flood the protocol with function calls and oracle requests, causing rapid LINK depletion, excessive oracle traffic, and increased costs.
This behavior affects both protocol stability and user experience, as LINK balances could be exhausted prematurely, disabling the automation for all users.
Likelihood:
Any user minting a Weather NFT can deliberately or accidentally set a zero or extremely low heartbeat
interval.
Automated or scripted mints can easily exploit this parameter.
Impact:
Rapid or infinite triggering of Chainlink Automation upkeeps, depleting LINK funds much faster than intended.
Denial of Service (DoS) for all protocol users relying on LINK for NFT automation.
Potential increased cost for the protocol (due to excessive Chainlink requests).
Manual Review
Custom Unit Testing (simulation of 0 and small heartbeat values)
Enforce Lower Bound in requestMintWeatherNFT
Add a require
at the top of requestMintWeatherNFT
to ensure the heartbeat
interval is greater than zero and above a practical minimum (e.g., 60 seconds):
This ensures heartbeat intervals are always reasonable and prevents rapid or infinite automation triggers, protecting protocol resources and user funds.
This is informational. It is user's responsibility to provide correct input arguments. If the user provides incorrect arguments, it will lead to incorrect results, lost funds or failed transaction.
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.