DatingDapp

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

Zero-Sentinel Profile Pattern Is Fragile Across Contract Boundary

[HIGH] Zero-Sentinel Profile Pattern Is Fragile Across Contract Boundary

File: sources/2025-02-datingdapp/src/SoulboundProfileNFT.sol
Lines: 35–40 | Also: LikeRegistry.sol L35–36

Summary

profileToToken uses 0 as a sentinel for "no profile". Token IDs start at 1 (via ++_nextTokenId), which is currently safe. However, this pattern creates a fragile cross-contract assumption: any future code path that writes 0 to the mapping, or any token-ID collision with 0, would allow profileless users to bypass the likeUser gate.

Vulnerability Details

// Zero used as sentinel — fragile
mapping(address => uint256) public profileToToken;
// LikeRegistry trusts this
require(profileToToken[msg.sender] != 0, "Must have a profile NFT");
require(profileToToken[liked] != 0, "Liked user must have a profile NFT");
// But nothing prevents profileToToken from being set to 0 by a future bug

Additionally, a user can burnProfile() and then mintProfile() again — the burn zeroes the mapping, but if the check in LikeRegistry is called in the same tx (e.g., via a flash-loan-like pattern), the burnt user might temporarily bypass checks depending on tx ordering.

Impact

  • Architectural fragility and latent security debt.

  • Cross-contract trust on a zero-sentinel is an anti-pattern that breaks when logic evolves.

Tools Used

  • Manual code review

Recommendations

Use an explicit boolean for profile existence:

+ mapping(address => bool) public hasProfile;
function mintProfile(...) external {
- require(profileToToken[msg.sender] == 0, "Profile already exists");
+ require(!hasProfile[msg.sender], "Profile already exists");
...
+ hasProfile[msg.sender] = true;
}
function burnProfile() external {
...
+ hasProfile[msg.sender] = false;
}
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 6 days 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!