Summary

The CustomReferralConfiguration library uses a hashing mechanism to calculate storage slots for custom referral configurations. However, this mechanism is susceptible to storage collisions, where different referral codes could potentially map to the same storage slot, leading to data overwriting and potential loss of referral information.

Vulnerability Details

The load function in the library calculates a storage slot based on the hash of the CUSTOM_REFERRAL_CONFIGURATION_DOMAIN constant and the customReferralCode input:

https://github.com/Cyfrin/2024-07-zaros/blob/main/src/perpetuals/leaves/CustomReferralConfiguration.sol#L16

While the keccak256 hash function is generally considered secure, there is still a non-zero probability of collisions, especially when dealing with a large number of referral codes. If two different referral codes hash to the same value, their configurations will be stored in the same slot, and one will overwrite the other.

Impact

If a collision occurs, the referral configuration associated with one code will be overwritten by another, leading to the loss of referral information and potentially incorrect tracking of referrals.

Tools Used

Manual review

Recommendations

Consider using a stronger hashing algorithm or a combination of hashing and salting techniques to reduce the probability of collisions. For example, you could use keccak256(abi.encodePacked(customReferralCode, salt)), where salt is a random value.