If follower follows by inputting an existing tokenId, he can be removed at anytime by the holder of that tokenId

[code423n4]

Lines of code

https://github.com/code-423n4/2023-07-lens/blob/main/contracts/FollowNFT.sol#L311-L339

Vulnerability details

Impact

Users that follow another profile by entering an existing followNFT tokenId can be removed at anytime by address that possesses the token.

This is because _followWithWrappedToken does not burn the token to withdraw power from the address that holds the token

Proof of Concept

Protocol allows users to follow a profile by using an existing tokenId from a profile that has approved the caller to do so. The problem is that, the address that owns that token(in case the token is wrapped), can call removeFollower at anytime to remove that follower.

For example,

• Alice follows Bob, minting a new tokenId 3
• Alice approves Charles to use her tokenId 3 to follow Bob
• Charles follows Bob, entering tokenId 3
  • tokenId 3 is not burned from Alice account, and Charles cannot mint tokenId 3 to himself
• Charles is not in full control as a follower, and Alice can call removeFollower to force Charles to unfollow Bob

Tools Used

Manual Review

Recommended Mitigation Steps

Within _baseFollow function, if (!isOriginalFollow), burn that tokenId. This will withdraw removeFollower power from the former token holder whenever a new profile registers with that token.

Assessed type

Access Control

[141345]

seems expected behavior the owner can rent, can take back

[donosonaumczuk]

It works like this by design. Is up to the follower when to take the risk or not. We expect this to be used with NFTs held by contracts, so the contract can guarantee that the "removeFollower" will be executed only under certains conditions. For example, you are renting the follow state by a monthly suscription, so "removeFollower" is only executed if your suscription was not paid, etc.

[c4-sponsor]

donosonaumczuk marked the issue as sponsor disputed

[c4-judge]

Picodes marked the issue as unsatisfactory: Invalid