52027 sc low whitelistrestrictions sol mint burn operations blocked when transfers disabled

#52027 [SC-Low] WhitelistRestrictions.sol: Mint & Burn Operations Blocked When Transfers Disabled

Submitted on Aug 7th 2025 at 12:00:44 UTC by @soloi for Attackathon | Plume Network

  • Report ID: #52027

  • Report Type: Smart Contract

  • Report severity: Low

  • Target: https://github.com/immunefi-team/attackathon-plume-network/blob/main/arc/src/restrictions/WhitelistRestrictions.sol

  • Impacts: Temporary freezing of funds for at least 24 hours

Description

WhitelistRestrictions.sol: Mint & Burn Operations Blocked When Transfers Disabled

Summary

The WhitelistRestrictions.sol contract contains a vulnerability where disabling the transfersAllowed flag also blocks all mint and burn operations, even for whitelisted users. This allows the admin to permanently disable core token functionality.

Vulnerability Details

Location

  • File: contracts/arc/src/restrictions/WhitelistRestrictions.sol

  • Lines: 95-102

  • Function: isTransferAllowed()

Root Cause

The isTransferAllowed() function treats all addresses equally, including the zero address (address(0)). When transfersAllowed is set to false, the function requires both the from and to addresses to be whitelisted. However, the zero address can never be whitelisted, causing mint and burn operations to fail.

Vulnerable Code

Technical Analysis

How Mint and Burn Operations Work

  • Minting: _mint(to, amount) calls _update(address(0), to, amount)

  • Burning: _burn(from, amount) calls _update(from, address(0), amount)

The Problem

When transfersAllowed = false:

  • Mint Operation: from = address(0), to = recipient

    • ws.isWhitelisted[address(0)] is always false (zero address can't be whitelisted)

    • ws.isWhitelisted[to] may be true (recipient is whitelisted)

    • Result: false && true = false → Mint blocked

  • Burn Operation: from = sender, to = address(0)

    • ws.isWhitelisted[from] may be true (sender is whitelisted)

    • ws.isWhitelisted[address(0)] is always false (zero address can't be whitelisted)

    • Result: true && false = false → Burn blocked

Impact Analysis

Severity: Medium

Immediate Consequences

  1. Permanent Disabling of Mint/Burn: Admin can permanently disable core token functionality

  2. Bricking Risk: Malicious admin could brick the token by disabling transfers

  3. Whitelist Bypass: Even whitelisted users cannot mint or burn tokens

  4. Functionality Loss: Core ERC20 operations become unavailable

Business Impact

  • Operational Risk: Inability to mint new tokens or burn existing ones

  • Admin Privilege Abuse: Single admin can disable critical functionality

  • User Experience: Legitimate users cannot perform expected operations

  • Compliance Risk: May violate regulatory requirements for token management

Attack Scenario

  1. Malicious Admin: Admin with ADMIN_ROLE calls setTransfersAllowed(false)

  2. Permanent Disablement: All mint and burn operations are permanently blocked

  3. No Recovery: Even if admin changes their mind, mint/burn remain blocked

  4. Token Bricking: Token becomes non-functional for core operations

Proof of Concept

A complete proof of concept demonstrating this vulnerability is available in: my_pocs/WhitelistRestrictions_MintBurn_PoC.t.sol

Proof-of-Concept test (expand to view)

Fix Recommendations

Immediate Fix

Add special handling for the zero address in isTransferAllowed():

Alternative Fix (More Granular Control)

If more granular control is desired:

Testing Requirements

1

Mint with Transfers Disabled

Verify minting works when transfersAllowed = false.

2

Burn with Transfers Disabled

Verify burning works when transfersAllowed = false.

3

Normal Transfer with Transfers Disabled

Verify normal transfers respect whitelist.

4

Admin Privilege Abuse

Test that admin cannot permanently brick functionality.

5

Edge Cases

Test with various combinations of whitelisted/non-whitelisted addresses.

Integration Testing

  • ArcToken Integration: Test with actual ArcToken contract

  • Multiple Restriction Modules: Test interaction with other restriction modules

  • Upgrade Scenarios: Test behavior after contract upgrades

Security Recommendations

Immediate Actions

1

Audit All Instances — Check if this pattern exists in other restriction modules.

2

Update Documentation — Document the correct behavior for mint/burn operations.

3

Admin Training — Ensure admins understand the implications of disabling transfers.

4

Monitoring — Add alerts for when transfers are disabled.

Long-term Improvements

1

Role Separation — Consider separating mint/burn permissions from transfer permissions.

2

Emergency Controls — Add emergency functions to re-enable mint/burn if needed.

3

Multi-sig Requirements — Require multiple signatures for critical operations.

4

Timelock — Add timelock for disabling transfers to prevent immediate bricking.

Conclusion

This vulnerability represents a significant design flaw in the WhitelistRestrictions contract that allows the admin to permanently disable core token functionality. The fix is straightforward and should be implemented immediately to prevent potential abuse.

Priority: Medium — Should be fixed promptly Impact: Admin can disable core token functionality Affected: All tokens using WhitelistRestrictions module

Was this helpful?