Skip to content

Latest commit

 

History

History
62 lines (34 loc) · 1.81 KB

037.md

File metadata and controls

62 lines (34 loc) · 1.81 KB

Tall Burgundy Nightingale

High

Blacklisted Addresses Can Still Interact Via defiSwap

Summary

Lack of blacklist validation in defiSwap function could accidentally allow blacklisted addresses to execute trades if a SWAPPER_ROLE processes their request without checking blacklist status, potentially undermining the blacklist security mechanism.

Root Cause

In AmirX.sol, the defiSwap function only checks if the wallet address is zero but fails to validate against the blacklist status:

https://github.com/sherlock-audit/2024-11-telcoin/blob/main/telcoin-audit/contracts/swap/AmirX.sol#L156-L164

Internal pre-conditions

Address needs to be blacklisted by blacklister role

SWAPPER_ROLE processes a swap request without manually checking blacklist status

Contract must not be paused

External pre-conditions

No response

Attack Path

Address gets blacklisted for legitimate reasons

Blacklisted address submits a swap request through normal channels

SWAPPER_ROLE, unaware of blacklist status, processes the request through defiSwap

Transaction succeeds despite blacklist status as there's no automatic check

Blacklisted address successfully executes trades

Impact

The effectiveness of the blacklist mechanism is reduced as blacklisted addresses might accidentally have their trades processed.

This creates additional operational burden on SWAPPER_ROLE who must manually check blacklist status, and increases the risk of accidental processing of blacklisted trades.

PoC

No response

Mitigation

Add automatic blacklist check in _verifyDefiSwap function:

function _verifyDefiSwap(address wallet, DefiSwap memory defi) internal view {
    // Add blacklist check here
    require(!Blacklist(stablecoin).blacklisted(wallet), "AmirX: wallet blacklisted");
    
    // existing checks...
}