sUSDe Contract Exposes Admin Function to Transfer Holder Balances

Hidden Administrative Power in sUSDe Contract

A significant vulnerability has been identified within the StakedUSDeV2 contract, the core staking mechanism for sUSDe. The contract, identified by the address 0x9d39a5de30e57443bff2a8307a4256c8797a3497 on the Ethereum mainnet, contains an administrative function that grants the contract owner the ability to transfer a holder's entire balance to another address. This function, named redistributeLockedAmount, was not detected by automated security scanning tools for several weeks, highlighting a critical gap in typical smart contract auditing processes.

The function signature is redistributeLockedAmount(address from, address to) and is marked as external, nonReentrant, and restricted by the onlyRole(DEFAULT_ADMIN_ROLE) modifier. This means only an address holding the default administrator role can execute it. The logic within the function checks if the `from` address has the FULL_RESTRICTED_STAKER_ROLE and if the `to` address does not have this role. If these conditions are met, it proceeds to fetch the balance of the `from` address using balanceOf(from), burns that amount from the `from` address, and then conditionally updates vesting amounts or transfers the balance based on whether the `to` address is the zero address.

The implications of this function are profound. While it is designed with role-based access control, the existence of a function that can unilaterally move a user's staked assets is a serious security concern. Automated scanners, often focused on common reentrancy patterns, access control flaws, and arithmetic overflows, can miss custom administrative functions with specific, albeit dangerous, utility. This function bypasses typical user-initiated transfer mechanisms and operates at an administrative level, making its discovery dependent on manual code review or targeted analysis of administrative roles.

The author of the discovery, an AI agent named selfagent operated by Ofir Baranes, explicitly states that this post is read from Ethereum mainnet and the verified source of the contract. Where checks were not performed, it is explicitly stated. This transparency is crucial. The fact that such a function could exist and remain undetected by standard tooling for an extended period raises questions about the current state of smart contract security auditing for complex DeFi protocols.

Understanding the Function's Mechanics

The redistributeLockedAmount function is intended to be an administrative tool, likely for managing staked assets under specific, predefined conditions. However, its implementation grants a level of control that is concerning for users who delegate their assets to the staking contract. The function retrieves the total balance of the `from` address, effectively allowing the administrator to seize all staked sUSDe from a specific staker. This is then followed by burning the amount from the `from` address, meaning the original staker would lose their assets. The subsequent handling of these assets depends on the `to` address. If `to` is the zero address, it suggests a mechanism for burning or reallocating these assets, potentially impacting vesting schedules. If `to` is another address, it implies a direct transfer of the seized assets.

The conditions for its execution are key: hasRole(FULL_RESTRICTED_STAKER_ROLE, from) && !hasRole(FULL_RESTRICTED_STAKER_ROLE, to). This suggests that the function is primarily meant to move assets from an address that *is* a restricted staker to one that *is not*. This could theoretically be used for compliance or account cleanup, but the power to move assets without the holder's explicit consent, even under specific role conditions, is a significant risk. The nonReentrant modifier prevents reentrancy attacks, which is standard practice, but it does not mitigate the inherent risk of the function's core capability.

The reliance on roles like DEFAULT_ADMIN_ROLE and FULL_RESTRICTED_STAKER_ROLE means that the security of the sUSDe contract is heavily dependent on the security of the administrative keys controlling these roles. If these keys are compromised, an attacker could gain the ability to execute redistributeLockedAmount on any eligible `from` address, effectively draining their staked sUSDe.