UxLink Multisig Ownership Compromise

This case study explains how the UxLink multisig ownership compromise worked and which assertion pattern could have constrained the invalid state transition.

What Happened

On September 22, 2025, UxLink’s multisig was compromised through private key theft, resulting in $11.3M direct theft plus unauthorized minting of 10 trillion tokens worth ~$28M. Attackers manipulated the multisig configuration to drain funds and gain token minting privileges.

Why It Worked

The attack exploited two weaknesses:

Compromised Private Keys: Attackers gained access to UxLink’s multisig owner private keys
Unrestricted Multisig Configuration: Safe contract allowed threshold reduction and owner changes without security checks
Token Minting Access: Compromised multisig gained Manager privileges over the UXLINK token contract

Attack Vector: Compromised private keys enabled execution of multisig transactions without validation or rate limiting.

Attack Analysis

Attack Sequence

Phase 1: Multisig Compromise Attackers used compromised private keys to revoke admin privileges, add themselves as owners, and reduce the multisig threshold to 1, gaining full control. Phase 2: Treasury Drainage Drained $11.3M in assets (USDT, USDC, WBTC, ETH) and converted them across chains. Phase 3: Token Exploitation Used multisig control to mint unlimited UXLINK tokens, causing a price crash and significant market cap loss.

Root Causes

Private Key Compromise: Compromised private keys due to poor operational security
No Multisig Protection: No safeguards against rapid configuration changes
No Rate Limiting: Multisig changes executed immediately without cooling periods
Missing Access Controls: No whitelisting for owner changes

Assertion Pattern

Multisig protection assertions could have prevented this attack by enforcing governance invariants:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.28;

import {Assertion} from "../../lib/credible-std/src/Assertion.sol";
import {AssertionSpec} from "../../lib/credible-std/src/SpecRecorder.sol";
import {PhEvm} from "../../lib/credible-std/src/PhEvm.sol";
import {ISafe} from "@safe-global/safe-contracts/contracts/interfaces/ISafe.sol";

contract UxLinkMultisigProtectionAssertion is Assertion {
    constructor() {
        registerAssertionSpec(AssertionSpec.Reshiram);
    }

    // Minimum threshold that must be maintained
    uint256 constant MIN_THRESHOLD = 2;

    // Whitelisted addresses that can become owners (set at deployment)
    address constant ALLOWED_OWNER_1 = 0x1111111111111111111111111111111111111111;
    address constant ALLOWED_OWNER_2 = 0x2222222222222222222222222222222222222222;
    address constant ALLOWED_OWNER_3 = 0x3333333333333333333333333333333333333333;

    function triggers() external view override {
        registerFnCallTrigger(
            this.assertThresholdProtection.selector,
            ISafe.changeThreshold.selector
        );

        registerFnCallTrigger(
            this.assertOwnerAddition.selector,
            ISafe.addOwnerWithThreshold.selector
        );

        registerFnCallTrigger(
            this.assertOwnerRemoval.selector,
            ISafe.removeOwner.selector
        );
    }

    /// @notice Prevents threshold reduction below minimum
    function assertThresholdProtection() external view {
        ISafe safe = ISafe(ph.getAssertionAdopter());

        PhEvm.CallInputs[] memory calls = ph.getCallInputs(
            address(safe),
            ISafe.changeThreshold.selector
        );

        for (uint256 i = 0; i < calls.length; i++) {
            uint256 newThreshold = abi.decode(calls[i].input, (uint256));

            // Never allow threshold below minimum
            require(newThreshold >= MIN_THRESHOLD, "Threshold cannot go below minimum");
        }
    }

    /// @notice Validates new owner additions against whitelist
    function assertOwnerAddition() external view {
        ISafe safe = ISafe(ph.getAssertionAdopter());

        PhEvm.CallInputs[] memory calls = ph.getCallInputs(
            address(safe),
            ISafe.addOwnerWithThreshold.selector
        );

        for (uint256 i = 0; i < calls.length; i++) {
            (address newOwner, uint256 threshold) = abi.decode(calls[i].input, (address, uint256));

            // Basic validation
            require(newOwner != address(0), "Invalid owner address");

            // Check whitelist
            require(
                newOwner == ALLOWED_OWNER_1 ||
                newOwner == ALLOWED_OWNER_2 ||
                newOwner == ALLOWED_OWNER_3,
                "New owner not whitelisted"
            );

            // Never allow threshold below minimum
            require(threshold >= MIN_THRESHOLD, "Threshold cannot go below minimum");
        }
    }

    /// @notice Validates owner removals don't reduce threshold below minimum
    function assertOwnerRemoval() external view {
        ISafe safe = ISafe(ph.getAssertionAdopter());

        PhEvm.CallInputs[] memory calls = ph.getCallInputs(
            address(safe),
            ISafe.removeOwner.selector
        );

        for (uint256 i = 0; i < calls.length; i++) {
            (, , uint256 threshold) = abi.decode(calls[i].input, (address, address, uint256));

            // Never allow threshold below minimum
            require(threshold >= MIN_THRESHOLD, "Threshold cannot go below minimum");
        }
    }
}

Assertions cannot track state across transactions (e.g., cooling periods). The original attack used rapid sequential transactions, which would require off-chain monitoring or timelocked governance contracts to fully prevent. However, the assertions above still provide strong protection by enforcing minimum thresholds and owner whitelisting.

How the Assertions Would Have Prevented It

What they do:

Threshold Protection: Prevents threshold from dropping below a safe minimum (e.g., 2)
Owner Whitelisting: Only allows pre-approved addresses to become owners
Removal Validation: Ensures owner removals don’t reduce threshold below minimum

How they prevent the attack:

Step 1: assertThresholdProtection() blocks any attempt to reduce threshold to 1
Step 2: assertOwnerAddition() blocks attacker addresses that aren’t whitelisted
Step 3: assertOwnerRemoval() ensures threshold stays above minimum even when removing owners
Result: Attacker cannot gain solo control of the multisig

Key insight: While these assertions can’t prevent private key compromise or enforce time delays between transactions, they establish hard boundaries that attackers cannot cross regardless of how many keys they control.

Key Takeaways

The UxLink attack shows that multisig security requires both operational security (private key protection) and protocol-level protections (configuration validation). The $39.3M total impact ($11.3M direct + $28M token minting) demonstrates how compromised private keys can lead to complete protocol takeover when governance controls are missing. Credible Layer assertions can enforce governance invariants: maintaining reasonable thresholds, validating owner changes, and preventing rapid reconfiguration. This approach ensures operational security failures don’t lead to complete protocol compromise.

Start Here

Explanation

Reference

What Happened

Why It Worked

Attack Analysis

Attack Sequence

Root Causes

Assertion Pattern

How the Assertions Would Have Prevented It

Key Takeaways

​What Happened

​Why It Worked

​Attack Analysis

​Attack Sequence

​Root Causes

​Assertion Pattern

​How the Assertions Would Have Prevented It

​Key Takeaways

What Happened

Why It Worked

Attack Analysis

Attack Sequence

Root Causes

Assertion Pattern

How the Assertions Would Have Prevented It

Key Takeaways