Hot Charcoal Orangutan - MEDIUM Admin Bypasses Profile Validation for Donation Recipient

[sherlock-admin3]

Hot Charcoal Orangutan

Medium

MEDIUM Admin Bypasses Profile Validation for Donation Recipient

Summary

The ReputationMarket:_createMarket function allows the admin to set any recipient as the donationRecipient for a profileId without enforcing the same validation rules present in ReputationMarket:updateDonationRecipient. Specifically, in ReputationMarket:updateDonationRecipient, the new recipient must be associated with the same profileId through the verifiedProfileIdForAddress function in the _ethosProfileContract.

When admin creates a market they can directly pass the receiver address. But when the current donation receiver wants to change the address, they wont be able to change the address because the checks in ReputationMarket:updateDonationRecipient won't let change.

https://github.com/sherlock-audit/2024-12-ethos-update/blob/main/ethos/packages/contracts/contracts/ReputationMarket.sol#L621

Root Cause

In ReputationMarket:_createMarket

uint256 recipientProfileId = _ethosProfileContract().verifiedProfileIdForAddress(newRecipient);
if (recipientProfileId != profileId) revert InvalidProfileId();

This ensures that the newRecipient should have the profile same as previous profile id which means the current donation receivers are not able to change the address

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

No response

Impact

The inconsistency in how the donationRecipient is updated creates an unfair limitation for users. Admins have the flexibility to set any recipient address when creating a market, even if the recipient does not have a verified profile matching the market's profileId. In contrast, current donation recipients are restricted by strict checks when attempting to update their address. Specifically, they cannot change the recipient address unless the new address has the same profileId as the market, which significantly limits their ability to make updates. This discrepancy leads to an inconsistent and unfair user experience, where admins can bypass validation rules that users are forced to follow. Such restrictions can frustrate legitimate recipients while also allowing admins to introduce potentially incorrect or unverified recipients, undermining trust and fairness in the system.

PoC

t this stage, a concrete PoC cannot be provided as the audited codebase is incomplete, and several related contracts (e.g., admin or profile validation contracts) are not implemented. However, based on the available code, the vulnerability can be theoretically outlined as follows:

• Admin Behavior: The admin can create a market and assign a donationRecipient without undergoing the strict validation checks imposed by updateDonationRecipient. This includes bypassing the profileId validation.
• User Restriction: A current donation recipient attempting to change the address is blocked by the updateDonationRecipient function's validation, which requires the new address to share the same profileId as the existing one.

Mitigation

Remove

if (recipientProfileId != profileId) revert InvalidProfileId();

this line or change conditons for admin in _createmarket according to how protocol should work