On February 21, 2025, the cryptocurrency exchange Bybit experienced a security breach, resulting in the loss of approximately $1.5 billion in ETH, potentially making it the largest cryptocurrency theft in history. The attack compromised Bybit's ETH multi-signature cold wallet during a routine transfer, exploiting a front-end vulnerability in Safe Wallet (formerly Gnosis Safe). Malicious code altered transaction data, ultimately draining funds from the multi-signature cold wallet. This report analyzes the technical principles and process behind the attack and provides recommendations for improving system design and security.
Safe Wallet is a widely adopted multi-signature wallet implementation, a smart contract design that requires multiple private key signatures to execute transactions. It enhances security through distributed authorization, supports various blockchain networks, and provides an intuitive front-end interface for user operations. The normal multi-signature transaction signing process is as follows:
The attack hinged on a combination of a supply chain attack and blind signing. The specific process unfolded as follows:
Front-End Supply Chain Attack:
Transaction Tampering and Blind Signing:
Malicious Contract Deployment and Execution:
Safe Wallet's smart contract employs an upgradeable architecture, consisting of a proxy contract and an implementation contract, which makes contract upgrades a prime target. The attacker manipulated the proxy contract using the delegatecall
function, tampering with callData
to replace the legitimate implementation with a malicious one. Specifically, the forged transaction data might have mimicked a transfer(address, uint256)
interface while actually executing contract upgrade logic, updating the implementation to a malicious version. Once updated, the backdoor functions in the malicious contract (sweepETH()
& sweepERC20()
) were triggered, enabling the transfer of funds. Analysis indicates that callData
tampering was the key factor in the attack's success, further aggravated by hardware wallets' inability to fully display callData
, thereby worsening the blind signing issue.
The wallet accounts, smart contracts, and executed transactions involved in this incident are as follows:
In Safe Wallet's design, the proxy contract uses a state variable named masterCopy
to store the address of the implementation contract, as a key factor of the upgrade functionality. This means the contract logic can be replaced. Normally, updating masterCopy
requires authorization from multiple signers and a formal process (e.g., calling upgradeTo(address)
).
However, in the Bybit hack, the attacker circumvented this formal process. By exploiting a front-end supply chain attack and callData
tampering, they manipulated transaction data to deceive signers into approving what appeared to be legitimate transfers or routine operations. In reality, the malicious callData
contained a pre-deployed malicious contract address. This method bypassed Safe Wallet's standard upgrade process by directly modifying masterCopy
, exploiting delegatecall
to alter its storage slot during proxy contract execution.
The normal multi-signature signing process highlights the secure operation of a multi-signature wallet. The proposer (Proposer
) creates a transaction and broadcasts its data to multiple signers (Signer1
, Signer2
, Signer3
) via the front-end. Each signer reviews and signs the transaction using their hardware wallet (e.g., Ledger). Once enough signatures are collected (e.g., three required), the system submits them to the wallet contract (WalletContract
) for transaction execution. This ensures multi-layer authorization and transparency, preventing unilateral actions.
The compromised signing process reveals the attack's operations. The attacker injects malicious code into the wallet front-end (WalletFrontend
), altering the displayed transaction data. The proposer (Proposer
) creates a legitimate transaction and broadcasts it, but the signers (Signer1
, Signer2
, Signer3
) see tampered data that appears valid. Due to hardware wallets' blind signing limitations (inability to display full callData
), signers approve the transaction unknowingly. Once submitted, the wallet contract (WalletContract
) executes the malicious transaction. This exposes the severe risks of supply chain attacks and UI deception.
To prevent such attacks, developers and operators should integrate the following measures into multi-signature wallet systems:
HSM
and FIDO2
IntegrationHardware Security Module (HSM
):
HSM
is a dedicated cryptographic device designed for secure private key storage and signing, which is commonly used in enterprise environments. Enterprise-level multi-signature systems can integrate an HSM
to ensure private keys never leave the device.HSM
to store private keys and sign transactions, reducing the risk of approving malicious operations.Fast Identity Online (FIDO
):
FIDO2
provides passwordless authentication using security keys or biometrics, which restricts signing interface access. Only FIDO2
-authenticated users can operate the front-end, which prevents unauthorized access.HSM
and FIDO2
creates a dual-layer security framework, thereby enhancing protection.To strengthen the security of institutional multi-signature wallet systems — especially in light of the Bybit hack, which exposed vulnerabilities such as front-end supply chain attacks, blind signing, and unauthorized contract upgrades — the following advanced techniques and strategies are recommended:
HSM
and FIDO2
Integration)HSM
devices for key storage and signing, ensuring keys remain offline.FIDO2
passwordless authentication with security keys or biometrics to ensure that only authorized users access the signing interface. The FIDO2
challenge-response mechanism prevents replay attacks, thereby enhancing access security.k ≤ n
) and storing them in HSM devices across different locations to prevent single-point failures or physical breaches.callData
integrity) and prevent the accidental approval of malicious transactions. Back-end validation of callData
against formal interfaces ensures consistency. Embed contextual parameters like timestamps, asset types, and whitelisted addresses, making signatures valid only under predefined conditions.callData
, frequent upgrades, large asset transfers, or interactions with high-risk addresses.callData
into natural language descriptions, highlighting key parameters such as contract address changes or permission modifications to aid signers in understanding transactions and avoiding UI deception.Application Layer:
callData
to prevent upgrade manipulations.Physical Layer:
HSM
hardware signing to ensure device integrity through regular checks and tamper-proof encapsulation, thereby preventing physical attacks.FIDO2
device authentication and challenge-response mechanisms for multi-layer verification, blocking unauthorized access.HSM
with FIDO2
to require dual-layer authentication, reducing social engineering risks.The Bybit hack exposed the fragility of multi-signature wallet systems to supply chain attacks and blind signing, making digital asset security an industry priority. By adopting multi-layer verification, HSM
and FIDO2
integration, and robust software security practices, developers and operators can significantly mitigate such risks. The blockchain industry must learn from this incident and advance secure system designs and operational standards to counter evolving threats. Moreover, adopting advanced prevention techniques — shifting assumptions from "preventing key leaks" to "assuming signing processes are susceptible to compromise" — is crucial to addressing complex attacks.
SecuX, a Web3 security solutions provider, is dedicated to developing and delivering advanced HSM
solutions and FIDO2
authentication technologies, offering enterprise-level cryptographic solutions to help clients counter these threats. SecuX's HSM
products provide secure key storage and management, while its FIDO2
solution leverages security key technology for passwordless authentication, ensuring Web3 security and operational integrity for digital asset management.