Upgradeable contract is deployed

Oct 13, 2025 by recoveryshake.com 54 views

Orbiting Cotton Piranha - Wrong check in initializeV1() in UsualX.sol

Introduction

In this article, we will be discussing a critical vulnerability found in the UsualX.sol contract. The vulnerability is related to a wrong check in the initializeV1() function, which can lead to a contract being stuck in an infinite loop, preventing the deployment of a new implementation contract. We will delve into the root cause of the issue, the internal and external pre-conditions, the attack path, and the impact of the vulnerability. Additionally, we will provide a proof-of-concept (PoC) code to demonstrate the vulnerability and suggest a mitigation strategy.

Summary

The contract is already deployed, and there is already a non-zero totalSupply. Now checking for totalSupply > 0 will always revert. This is because the contract is already initialized, and the initializeV1() function is trying to initialize it again, which is causing the revert.

Root Cause

The root cause of the issue is the wrong check in the initializeV1() function. The function is checking if totalSupply > 0, but since the contract is already deployed and initialized, the totalSupply is already non-zero. This causes the function to revert, preventing the deployment of a new implementation contract.

Internal Pre-conditions

Upgradeable contract is deployed: The contract is already deployed, and it has a non-zero totalSupply.
There is already non-zero totalSupply: The contract has already been initialized, and the totalSupply is non-zero.

External Pre-conditions

New implementation contract needs to be deployed: A new implementation contract needs to be deployed, but the initializeV1() function is preventing it.

Attack Path

Upgradeable contract is deployed: The contract is already deployed, and it has a non-zero totalSupply.
There is already non-zero totalSupply: The contract has already been initialized, and the totalSupply is non-zero.
New implementation contract UsualX.sol needs to be deployed: A new implementation contract needs to be deployed, but the initializeV1() function is preventing it.

Impact

The impact of the vulnerability is that the contract will keep reverting, preventing the deployment of a new implementation contract. This can lead to a situation where the contract is stuck in an infinite loop, making it impossible to deploy a new implementation contract.

PoC

The proof-of-concept (PoC) code is provided below:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import {console} from "forge-std/console.sol";
import {UsualX} from "src/vaults/UsualX.sol";
import {IERC20} from "openzeppelin-contracts/token/ERC20/extensions/ERC4626.sol";
import {
    INITIAL_ACCUMULATED_FEES,
    INITIAL_SHARES_MINTING
} from "src/constants.sol";

interface IUsualX {
    event Initialized(uint64 version);

    struct UsualXStorageV0 {
        /// @notice The fee charged on withdrawals
        uint256 withdrawFeeBps;
        /// @notice The RegistryAccess contract instance for role checks.
        address registryAccess;
        /// @notice The RegistryContract instance for contract interactions.
        address registryContract;
        /// @notice The blacklisted users mapping
        mapping(address => bool) isBlacklisted;
        /// @notice The USUAL token address
        address usualToken;
        /// @notice The accumulated withdrawal fees
        uint256 accumulatedFees;
        /// @notice The percentage of fees to burn when sweeping (in basis points)
        uint256 burnRatioBps;
    }
    function totalSupply() external view returns (uint256);
    function asset() external view returns (address);
}

contract ForkTest1 is Test {
    UsualX v1;

     // Ethereum Mainnet address from Usual Tech Docs
    address proxy = 0x06B964d96f5dCF7Eae9d7C559B09EDCe244d4B8E;

    bytes32 IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;
    
    // keccak256(abi.encode(uint256(keccak256("usualX.storage.v0")) - 1)) & ~bytes32(uint256(0xff))
    bytes32 public constant UsualXStorageV0Location =
        0xe34b7e189bdc1dc8307eb679fcc632f366df79571fb57039f593735b96795300;
    
    function _resetInitializerImplementation(address implementation) internal {
        // keccak256(abi.encode(uint256(keccak256("openzeppelin.storage.Initializable")) - 1)) & ~bytes32(uint256(0xff))
        bytes32 INITIALIZABLE_STORAGE =
            0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00;
        // Set the storage slot to uninitialized
        vm.store(address(implementation), INITIALIZABLE_STORAGE, 0);
    }

    function test_poc_1() public {
        address usualX = address(uint160(uint256(vm.load(proxy, IMPLEMENTATION_SLOT))));
        //Deployed Implementation address from etherscan
        assertEq(usualX, address(0xb8819CD07B042b4F514E4aB381f675614CB7B37d));
        // Read `withdrawFeeBps` (uint256 at first slot)
        bytes32 _withdrawFeeBpsRaw = vm.load(proxy, UsualXStorageV0Location);
        assertEq(uint256(_withdrawFeeBpsRaw), 1000);
        uint256 _totalSupply = IUsualX(proxy).totalSupply();
        assertNotEq(_totalSupply, 0);        
        IERC20 _asset = IERC20(IUsualX(proxy).asset());
        assertNotEq(_asset.balanceOf(proxy), 0);

        v1 = new UsualX();
        v1 = UsualX(proxy);
        assertNotEq(uint256(uint160(address(usualX))), uint256(uint160(address(v1))));
        _resetInitializerImplementation(address(v1));
        vm.expectRevert();
        v1.initializeV1(0, _totalSupply);

    }    
}

To run the test, use the following command:

forge test --fork-url https://eth-mainnet.g.alchemy.com/v2/RPC_URL --mt test_poc_1 --mc ForkTest1 -vvvvv

Mitigation

To mitigate this vulnerability, the initializeV1() function should be modified to check if the contract is already initialized before trying to initialize it again. This can be done by checking the initialized flag in the contract's storage. If the contract is already initialized, the function should return without trying to initialize it again.

Here is an example of how the initializeV1() function can be modified:

function initializeV1(uint256 _initialAccumulatedFees, uint256 _initialSharesMinting) public {
    // Check if the contract is already initialized
    if (initialized()) {
        return;
    }
    // Initialize the contract
    // ...
}

Note that this is just one possible way to mitigate the vulnerability, and the actual solution may depend on the specific requirements and constraints of the contract.
Orbiting Cotton Piranha - Wrong check in initializeV1() in UsualX.sol - Q&A

Introduction

In our previous article, we discussed a critical vulnerability found in the UsualX.sol contract. The vulnerability is related to a wrong check in the initializeV1() function, which can lead to a contract being stuck in an infinite loop, preventing the deployment of a new implementation contract. In this article, we will answer some frequently asked questions (FAQs) related to this vulnerability.

Q: What is the root cause of the vulnerability?

A: The root cause of the vulnerability is the wrong check in the initializeV1() function. The function is checking if totalSupply > 0, but since the contract is already deployed and initialized, the totalSupply is already non-zero. This causes the function to revert, preventing the deployment of a new implementation contract.

Q: What are the internal pre-conditions for this vulnerability?

A: The internal pre-conditions for this vulnerability are:

Upgradeable contract is deployed: The contract is already deployed, and it has a non-zero totalSupply.
There is already non-zero totalSupply: The contract has already been initialized, and the totalSupply is non-zero.

Q: What are the external pre-conditions for this vulnerability?

A: The external pre-conditions for this vulnerability are:

New implementation contract needs to be deployed: A new implementation contract needs to be deployed, but the initializeV1() function is preventing it.

Q: What is the attack path for this vulnerability?

A: The attack path for this vulnerability is:

Upgradeable contract is deployed: The contract is already deployed, and it has a non-zero totalSupply.
There is already non-zero totalSupply: The contract has already been initialized, and the totalSupply is non-zero.
New implementation contract UsualX.sol needs to be deployed: A new implementation contract needs to be deployed, but the initializeV1() function is preventing it.

Q: What is the impact of this vulnerability?

A: The impact of this vulnerability is that the contract will keep reverting, preventing the deployment of a new implementation contract. This can lead to a situation where the contract is stuck in an infinite loop, making it impossible to deploy a new implementation contract.

Q: How can I mitigate this vulnerability?

A: To mitigate this vulnerability, the initializeV1() function should be modified to check if the contract is already initialized before trying to initialize it again. This can be done by checking the initialized flag in the contract's storage. If the contract is already initialized, the function should return without trying to initialize it again.

Q: What is the proof-of-concept (PoC) code for this vulnerability?

A: The proof-of-concept (PoC) code for this vulnerability is provided below:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import {console} from "forge-std/console.sol";
import {UsualX} from "src/vaults/UsualX.sol";
import {IERC20} from "openzeppelin-contracts/token/ERC20/extensions/ERC4626.sol";
import {
    INITIAL_ACCUMULATED_FEES,
    INITIAL_SHARES_MINTING
} from "src/constants.sol";

interface IUsualX {
    event Initialized(uint64 version);

    struct UsualXStorageV0 {
        /// @notice The fee charged on withdrawals
        uint256 withdrawFeeBps;
        /// @notice The RegistryAccess contract instance for role checks.
        address registryAccess;
        /// @notice The RegistryContract instance for contract interactions.
        address registryContract;
        /// @notice The blacklisted users mapping
        mapping(address => bool) isBlacklisted;
        /// @notice The USUAL token address
        address usualToken;
        /// @notice The accumulated withdrawal fees
        uint256 accumulatedFees;
        /// @notice The percentage of fees to burn when sweeping (in basis points)
        uint256 burnRatioBps;
    }
    function totalSupply() external view returns (uint256);
    function asset() external view returns (address);
}

contract ForkTest1 is Test {
    UsualX v1;

     // Ethereum Mainnet address from Usual Tech Docs
    address proxy = 0x06B964d96f5dCF7Eae9d7C559B09EDCe244d4B8E;

    bytes32 IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;
    
    // keccak256(abi.encode(uint256(keccak256("usualX.storage.v0")) - 1)) & ~bytes32(uint256(0xff))
    bytes32 public constant UsualXStorageV0Location =
        0xe34b7e189bdc1dc8307eb679fcc632f366df79571fb57039f593735b96795300;
    
    function _resetInitializerImplementation(address implementation) internal {
        // keccak256(abi.encode(uint256(keccak256("openzeppelin.storage.Initializable")) - 1)) & ~bytes32(uint256(0xff))
        bytes32 INITIALIZABLE_STORAGE =
            0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00;
        // Set the storage slot to uninitialized
        vm.store(address(implementation), INITIALIZABLE_STORAGE, 0);
    }

    function test_poc_1() public {
        address usualX = address(uint160(uint256(vm.load(proxy, IMPLEMENTATION_SLOT))));
        //Deployed Implementation address from etherscan
        assertEq(usualX, address(0xb8819CD07B042b4F514E4aB381f675614CB7B37d));
        // Read `withdrawFeeBps` (uint256 at first slot)
        bytes32 _withdrawFeeBpsRaw = vm.load(proxy, UsualXStorageV0Location);
        assertEq(uint256(_withdrawFeeBpsRaw), 1000);
        uint256 _totalSupply = IUsualX(proxy).totalSupply();
        assertNotEq(_totalSupply, 0);        
        IERC20 _asset = IERC20(IUsualX(proxy).asset());
        assertNotEq(_asset.balanceOf(proxy), 0);

        v1 = new UsualX();
        v1 = UsualX(proxy);
        assertNotEq(uint256(uint160(address(usualX))), uint256(uint160(address(v1))));
        _resetInitializerImplementation(address(v1));
        vm.expectRevert();
        v1.initializeV1(0, _totalSupply);

    }    
}

To run the test, use the following command:

forge test --fork-url https://eth-mainnet.g.alchemy.com/v2/RPC_URL --mt test_poc_1 --mc ForkTest1 -vvvvv

Q: How can I prevent this vulnerability in my own contracts?

A: To prevent this vulnerability in your own contracts, make sure to check if the contract is already initialized before trying to initialize it again. This can be done by checking the initialized flag in the contract's storage. If the contract is already initialized, the function should return without trying to initialize it again.

Q: What are some best practices for preventing this type of vulnerability?

A: Some best practices for preventing this type of vulnerability include:

Checking for initialization: Before trying to initialize a contract, check if it is already initialized.
Using a flag: Use a flag to indicate whether the contract has been initialized.
Checking for existing contracts: Before deploying a new contract, check if an existing contract with the same name already exists.
Using a naming convention: Use a naming convention to avoid conflicts between contracts.

By following these best practices, you can help prevent this type of vulnerability in your own contracts.