Albort - Potential for Unauthorized Rebate Adjustments in AddSubRebate

[sherlock-admin4]

Albort

Medium

Potential for Unauthorized Rebate Adjustments in AddSubRebate

Summary

Vulnerability Detail

In the AddSubRebate instruction, any authority that is either the rebate_manager.authority or an admin_authority can add or subtract pending rebates from any RebateInfo account:

#[derive(Accounts)]
pub struct AddSubRebate<'info> {
    pub authority: Signer<'info>,

    // Other accounts...

    #[account(mut,
        has_one = rebate_manager,
        has_one = rebate_authority,
    )]
    pub rebate_info: Account<'info, RebateInfo>,
}

Since rebate_authority is an unchecked account and can be any account, an admin could potentially manipulate the pending_rebate of any RebateInfo, including their own, leading to unauthorized fund claims.

Impact

Code Snippet

https://github.com/sherlock-audit/2024-08-woofi-solana-deployment/blob/main/WOOFi_Solana/programs/rebate_manager/src/instructions/admin/add_sub_rebate.rs#L9

Tool used

Manual Review

Recommendation

Introduce additional constraints or checks to ensure that only authorized actions can be taken on a RebateInfo. For example, you might require that only the rebate_manager.authority (not admin_authority) can adjust rebates, or you might include logic to prevent admins from adjusting rebates for accounts they control.

[toprince]

Not valid.
rebate_authority means third party channel who is the owner of the rebate fee.