Soulmate waiting to reunite can get an unexpectedly high amount of LoveTokens in AirdropVault to be airdropped. As the idToCreationTimestamp of the token has not been set yet, it equals zero, the calculation of the tokenAmountToDistribute is then too high
The attacker calls mintSoulmateToken() after the emission of SoulmateAreReunited (so that he is the first in the couple)
The attacker then can claim an airdrop :
As the soulmateContract.idToCreationTimestamp(soulmateContract.ownerToId(msg.sender))
is not set up yet, this will be equal to 0
numberOfDaysInCouple
is then equal to "block.timestamp / daysInSecond" ( approx equals to 20000)
Then the uint256 tokenAmountToDistribute = (numberOfDaysInCouple * 10 ** loveToken.decimals()) - amountAlreadyClaimed;
is very high, resulting in
to be higher than expected
Users can be airdropped a overevaluated amount of tokens.
Manual review
Check if msg.sender has a soulmate
High severity, This issue is separated from the flawed `isDivorced()` check presented in issue #168 as even if that is fixed, if ownership is not checked, isDivorced would still default to false and allow bypass to claim airdrops by posing as tokenId 0 in turn resulting in this [important check for token claim is bypassed.](https://github.com/Cyfrin/2024-02-soulmate/blob/b3f9227942ffd5c443ce6bccaa980fea0304c38f/src/Airdrop.sol#L61-L66). #220 is the most comprehensive issue as it correctly recognizes both issues existing within the same function.
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.