50784 sc high any arc token creator can upgrade the implementation

Submitted on Jul 28th 2025 at 14:40:31 UTC by @jovi for Attackathon | Plume Network

• Report ID: #50784

• Report Type: Smart Contract

• Report severity: High

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

• Impacts:

  • Permanent freezing of funds

  • Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield

  • Unauthorized upgrade of Arc Token implementation

High severity: attackers with the described capability can permanently compromise user funds and token behavior.

Description

Brief / Intro

The DEFAULT_ADMIN_ROLE is the (implicit) admin of UPGRADER_ROLE, so every Arc‑token creator can instantly grant themselves upgrade power, swap in malicious logic, and steal or freeze purchaser funds. Since the Arc-token is portrayed as an official and trusted token implementation for Plume, this behavior is unlikely to be removed from the official UI before mitigations are implemented.

Vulnerability Details

When ArcTokenFactory initializes a new token it passes msg.sender as DEFAULT_ADMIN_ROLE (see: https://github.com/immunefi-team/attackathon-plume-network/blob/main/arc/src/ArcTokenFactory.sol#L193). In OpenZeppelin AccessControlUpgradeable, every custom role’s admin defaults to DEFAULT_ADMIN_ROLE unless explicitly overridden. Therefore the creator can immediately call grantRole(UPGRADER_ROLE, self) and gain unrestricted control over the proxy’s implementation — the correct flow, however, would be to only allow the token factory to retain this role (see: https://github.com/immunefi-team/attackathon-plume-network/blob/main/arc/src/ArcTokenFactory.sol#L200).

This enables the ArcToken creator to grant themselves the UPGRADER_ROLE.

Impact Details

Any ArcToken creator is able to modify their created token implementation. This enables exploitative behavior in multiple fronts:

• Modified transfer implementations can permanently freeze user funds.

• Modified balance accounting can enable funds to be removed or added arbitrarily.

• ArcToken purchases can be honeypot: malicious arc token providers can create sales with excessive yield to lure users into purchasing their tokens, receive the earnings from the offering, then rug-pull the token by changing its implementation and claiming the whole yield back to themselves.

Proof of Concept

1

Create a token

Someone creates an Arc token.

2

Grant upgrader

The creator then grants themself the UPGRADER_ROLE.

3

Execute malicious upgrade

The creator can decide when to act maliciously. For example, they can wait for volume on the token, execute honeypot actions to attract purchases, then upgrade the implementation to a malicious one that:

• Freezes transfers,

• Reassigns or mints balances to the attacker,

• Or otherwise drains funds.

References

• Contract: https://github.com/immunefi-team/attackathon-plume-network/blob/main/arc/src/ArcTokenFactory.sol