Weather Witness
First Flight #40
Beginner FriendlyFoundrySolidityNFT
100 EXP
View results
Previous Next
Submission Details
Impact: high
Likelihood: low
Invalid

NFT Token Transfer Disrupts Keeper Automation and Data Consistency

20162020lxm

title

NFT Token Transfer Disrupts Keeper Automation and Data Consistency

Description

The WeatherNFT contract fails to properly handle Chainlink Keeper registrations and weather data updates when NFTs are transferred between addresses. This creates inconsistencies between NFT ownership and the automated services tied to each token.

Root Cause

The contract implements token transfers through standard ERC721 functionality but doesn't account for:

  1. Keeper registration continuity

  2. Weather data update permissions

  3. LINK token expenditure responsibility

// Current transfer implementation lacks Keeper handling
function _transfer(address from, address to, uint256 tokenId) internal override {
super._transfer(from, to, tokenId);
// Missing Keeper and data update logic
}

Internal pre-conditions

  1. NFT has active Chainlink Keeper registration

  2. Regular weather data updates are scheduled

  3. LINK tokens are deposited for automation

  4. No transfer restrictions implemented

External pre-conditions

  1. Standard ERC721 transfer operations

  2. Active Chainlink network services

  3. Valid Keeper registrations

  4. Sufficient LINK token balances

Attack Path

  1. Attacker acquires NFT through normal transfer

  2. Original owner's Keeper continues operating

  3. New owner receives NFT but no control over:

    • Update frequency

    • Data sources

    • Keeper parameters

  4. Contract continues spending original owner's LINK

  5. Weather updates mismatch ownership

Risk

  1. Financial Risks:

    • LINK token loss from orphaned Keepers

    • Unauthorized fund deductions

    • Irreversible automation costs

  2. Operational Risks:

    • Broken automation workflows

    • Mismatched data ownership

    • Uncontrolled API calls

  3. Compliance Risks:

    • Violation of data privacy

    • Unauthorized data access

    • Regulatory reporting issues

  4. Reputation Risks:

    • User distrust in automation

    • Negative protocol perception

    • Loss of stakeholder confidence

Impact

  1. Financial loss:

    • Original owner pays for unwanted services

    • New owner cannot utilize paid features

  2. Functional issues:

    • Automated updates to wrong addresses

    • Mismatched data permissions

  3. Trust erosion:

    • Unclear service ownership

    • Unexpected LINK token deductions

  4. System instability:

    • Orphaned Keeper registrations

    • Unauthorized data modifications

PoC

  1. Mint NFT with Keeper registration

  2. Transfer NFT to new address

  3. Verify:

    • Original Keeper still active

    • New owner can't modify settings

    • LINK deductions continue

    • Updates use old parameters

Mitigation

  1. Implement transfer hooks:

function _beforeTokenTransfer(
address from,
address to,
uint256 tokenId
) internal override {
if (from != address(0)) {
WeatherNftInfo storage info = s_weatherNftInfo[tokenId];
if (info.upkeepId != 0) {
// Cancel existing upkeep
IAutomationRegistryMaster(s_keeperRegistry)
.cancelUpkeep(info.upkeepId);
info.upkeepId = 0;
}
}
super._beforeTokenTransfer(from, to, tokenId);
}

  1. Add Keeper transfer function:

function transferUpkeep(uint256 tokenId, address newOwner) external {
require(ownerOf(tokenId) == msg.sender, "Not owner");
s_weatherNftInfo[tokenId].upkeepAdmin = newOwner;
}

  1. Require explicit Keeper re-registration after transfer

  2. Implement LINK token reimbursement mechanism

Updates

Appeal created

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

Support

FAQs

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