# Malicious users can bypass the blacklist.

Midas mTBILL enforces its blacklist via an OpenZeppelin role, so a blacklisted user can call renounceRole to drop BLACKLISTED_ROLE and transfer funds again.

- Payout: Contest reward
- Severity: high
- Program: Midas
- Credited: 0xloscar01
- Disclosed: 2024-05-22
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-midas-judging/issues/9
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-midas%3AH-1
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** mTBILL ERC20 token / Blacklistable access control
**Root cause:** Blacklist is implemented as a revocable AccessControl role (BLACKLISTED_ROLE) checked in _beforeTokenTransfer, but OpenZeppelin's renounceRole lets the account itself revoke that role.
**Steps:**
1. Protocol grants BLACKLISTED_ROLE to a malicious account via Blacklistable.
2. Account calls `renounceRole(BLACKLISTED_ROLE, self)` on the token contract.
3. onlyNotRole check in _onlyNotBlacklisted now passes.
4. Account transfers mTBILL freely, bypassing the blacklist.
**How found:** Code reading: noticed blacklist enforced via role rather than a dedicated mapping, then recalled OpenZeppelin AccessControlUpgradeable exposes renounceRole allowing self-revocation.
**Exploitation:** A blacklisted holder simply calls renounceRole for its own BLACKLISTED_ROLE, clearing the onlyNotBlacklisted guard, then transfers/sells mTBILL on secondary markets like Morpho.
**Escalation:** Blacklisted funds remain liquid and can be sold into secondary markets holding ~30% of mTBILL supply.
**Insight:** When a blacklist/denylist is modeled as an AccessControl role, check whether the subject can self-revoke it via renounceRole; denylists must be non-self-revocable state, not roles.