DatingDapp

AI First Flight #6
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Submission Details
Severity: medium
Valid

Ambiguous profileToToken == 0 Trust Assumption Between Contracts

Description

  • Normal behavior: LikeRegistry.likeUser()'s require(profileNFT.profileToToken(msg.sender) != 0, ...) should reliably tell it whether an address is a currently-eligible, registered user.

  • Specific issue: profileToToken[addr] == 0 cannot distinguish "never registered" from "registered, then blocked" — both collapse to the same value, so the guard's cross-contract trust assumption is ambiguous.

require(profileNFT.profileToToken(msg.sender) != 0, "Must have a profile NFT"); // @> can't distinguish "never registered" from "blocked then reset" — same value (0) either way

Risk

Likelihood:

  • Only manifests once submission #4 (blockProfile non-persistence) is fixed with a naive default-value check instead of an explicit eligibility check — otherwise it's currently masked by #4 itself (a blocked user can already re-mint anyway).

Impact:

  • Purely a cross-contract data-interpretation gap, not independently exploitable — impact is limited to correctness of future moderation logic once #4 is patched.

Proof of Concept

No PoC is included: this finding describes an ambiguity in what a return value means, not a state that can be asserted wrong via a test — profileToToken(addr) == 0 is exactly as correct/incorrect for a never-registered address as for a blocked one, by design of the current mapping. The issue is demonstrated by inspection: both scenarios are provably indistinguishable from the caller's side.

Recommended Mitigation

Rather than have every caller re-derive eligibility from raw mapping reads, SoulboundProfileNFT exposes a single isEligible() view that already accounts for both "never registered" and "blocked" cases. LikeRegistry then only needs one cross-contract call per check instead of interpreting a possibly-ambiguous return value itself.

+ function isEligible(address user) external view returns (bool) {
+ return profileToToken[user] != 0 && !isBlocked[user];
+ }

Have LikeRegistry call isEligible() instead of reading profileToToken directly, once the isBlocked mapping from submission #4 exists.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 1 day ago
Submission Judgement Published
Validated
Assigned finding tags:

[M-01] `SoulboundProfileNFT::blockProfile` make it possible to recreate the profile

## Description The `SoulboundProfileNFT::blockProfile` function uses `delete profileToToken[blockAddress]`, which resets `profileToToken[blockAddress]` to `0`. Since the mintProfile function checks for an existing profile by verifying that `profileToToken[msg.sender] == 0`, a blocked account can be recreated by simply minting a new profile. This behavior bypasses the intended permanent block functionality. ## Vulnerability Details By deleting the mapping entry for a blocked account, the contract inadvertently allows a new mintProfile call to pass the check `require(profileToToken[msg.sender] == 0, "Profile already exists")`. Essentially, once an account is blocked, its associated mapping entry is cleared, so the condition to identify an account with an existing profile is no longer met. This loophole enables a blocked account to recreate its profile, undermining the purpose of blocking. ## Impact A blocked account, which should be permanently barred from engaging with the platform, can circumvent this restriction by re-minting its profile. The integrity of the platform is compromised, as blocked users could regain access and potentially perform further malicious actions. ## POC ```solidity function testRecereationOfBlockedAccount() public { // Alice mints a profile successfully vm.prank(user); soulboundNFT.mintProfile("Alice", 18, "ipfs://profileImageAlice"); // Owner blocks Alice's account, which deletes Alice profile mapping vm.prank(owner); soulboundNFT.blockProfile(user); // The blocked user (Alice) attempts to mint a new profile. // Due to the reset mapping value (0), the require check is bypassed. vm.prank(user); soulboundNFT.mintProfile("Alice", 18, "ipfs://profileImageAlice"); } ``` ## Recommendations - When blocking an account, implement a mechanism to permanently mark that address as blocked rather than simply deleting an entry. For example, maintain a separate mapping (e.g., isBlocked) to record blocked accounts, and update mintProfile to check if an account is permanently barred from minting: Example modification: ```diff + mapping(address => bool) public isBlocked; ... function mintProfile(string memory name, uint8 age, string memory profileImage) external { + require(!isBlocked[msg.sender], "Account is permanently blocked"); require(profileToToken[msg.sender] == 0, "Profile already exists"); uint256 tokenId = ++_nextTokenId; _safeMint(msg.sender, tokenId); // Store metadata on-chain _profiles[tokenId] = Profile(name, age, profileImage); profileToToken[msg.sender] = tokenId; emit ProfileMinted(msg.sender, tokenId, name, age, profileImage); } ... function blockProfile(address blockAddress) external onlyOwner { uint256 tokenId = profileToToken[blockAddress]; require(tokenId != 0, "No profile found"); _burn(tokenId); delete profileToToken[blockAddress]; delete _profiles[tokenId]; + isBlocked[blockAddress] = true; emit ProfileBurned(blockAddress, tokenId); } ```

Support

FAQs

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

Give us feedback!