Users who are present in both the whitelist and the presale list can use both privileges

[hats-bug-reporter[bot]]

Github username: @aviggiano Submission hash (on-chain): 0x07c9f847f38879940a356f2aa64a50d010aaf3b0fd47d5be78809251400bf316 Severity: medium

Description:

Description

In the Ibo.sol:187, the contract does not prevent a user who is present in both the whitelist and the presale list from using both privileges. If a user should only use one of the whitelists (which can be assumed as the norm), the contract should maintain a tracking mechanism to prevent multiple privileges.

Attack scenario

An attacker who is present in both the whitelist and presale list can misuse their status to enhance their profits, causing an unbalanced token distribution and a lack of fairness in token allocation.

Proof of Concept

cvgToSold = depositedUsdValue / _computeCvgBondUsdPrice(CVG_PRICE_NO_ROI, _bondParams, _iboStartTimestamp, _totalCvgDue);
if (isPrivilege) {
    // @audit-issue M-02 Users who are present in both the whitelist and the presale list can use both privileges.
    uint256 newValueSold = soldDuringPrivilege[msg.sender] + cvgToSold;
    if (privilegeType == 0) {
        require(newValueSold <= MAX_CVG_PEPE_PRIVILEGE, "MAX_CVG_PEPE_PRIVILEGE");
    } else {
        require(newValueSold <= MAX_CVG_WL_PRIVILEGE, "MAX_CVG_WL_PRIVILEGE");
    }
    soldDuringPrivilege[msg.sender] = newValueSold;
}

Here, a sender who holds both privilege types can make use of both privileges, leading to potential unbalanced token distribution.

Recommendation

Implement a check to affirm that users present in both lists (whitelist and presale) are only allowed to use any one of the privileges at a time. This can be done by storing the privilege details of each user during their first deposit and restricting subsequent transactions with the other privilege.

[0xR3vert]

Hello, Thanks a lot for your attention. We don't consider misconfiguration as an issue. Also we are aware of this and have already an duplicate checker in our backend between both merkletrees. In conclusion we have so to consider this issue as invalid.