Open sherlock-admin3 opened 2 months ago
https://github.com/sherlock-audit/2024-08-woofi-solana-deployment/blob/main/WOOFi_Solana/programs/rebate_manager/src/instructions/admin/create_rebate_info.rs#L9-L19 constraint = rebate_manager.authority == authority.key() || rebate_manager.admin_authority.contains(authority.key),
Valid, due to above constraints, should be low impact.
The protocol team fixed this issue in the following PRs/commits: https://github.com/woonetwork/WOOFi_Solana/pull/28
Albort
Medium
Inconsistent Authority Constraints in
ClaimRebateFee
Summary
Vulnerability Detail
In the
ClaimRebateFee
instruction, you have the following constraint:This constraint requires that
rebate_info.authority == rebate_manager.authority
. However, when you create aRebateInfo
account in theCreateRebateInfo
instruction, the authority is set to theauthority
who calls the instruction, not necessarily therebate_manager.authority
:This mismatch means that unless the
rebate_manager.authority
itself creates theRebateInfo
, any other users who create aRebateInfo
will have an authority that doesn't matchrebate_manager.authority
, preventing them from claiming their rebates. This effectively blocks legitimate rebate claims from users who are supposed to be able to claim their pending rebates.Impact
Code Snippet
https://github.com/sherlock-audit/2024-08-woofi-solana-deployment/blob/main/WOOFi_Solana/programs/rebate_manager/src/instructions/claim_rebate_fee.rs#L23
https://github.com/sherlock-audit/2024-08-woofi-solana-deployment/blob/main/WOOFi_Solana/programs/rebate_manager/src/instructions/admin/create_rebate_info.rs#L38
Tool used
Manual Review
Recommendation
Modify the
CreateRebateInfo
instruction to set therebate_info.authority
torebate_manager.authority
instead ofctx.accounts.authority.key()
. This ensures consistency and allows theClaimRebateFee
instruction to proceed as intended.