Multisignature wallets have long been considered the gold standard for securing large cryptocurrency holdings. The logic is straightforward: requiring multiple independent approvals for any transaction should make it exponentially harder for an attacker to steal funds. Yet the $1.5 billion Bybit hack on February 21, 2025, demonstrated that multisig security is only as strong as its weakest link. By February 27, when the FBI confirmed North Korea’s TraderTraitor group as the attacker, the crypto industry was forced to confront uncomfortable truths about multisig vulnerabilities.
Understanding how multisig wallets can be compromised is essential for anyone relying on them, whether you are an individual with a Gnosis Safe setup or an exchange managing billions in customer funds. This guide examines the specific attack vectors that have been exploited in real-world incidents and provides concrete guidance on how to harden your multisig configuration against them.
How Multisig Works
A multisignature wallet requires a predetermined number of signers to approve a transaction before it can be executed. The most common configuration is M-of-N, where N is the total number of authorized signers and M is the minimum number required to approve. A 3-of-5 setup, for example, requires any three of five authorized signers to approve a transaction.
The security model relies on the assumption that each signer operates independently and verifies transactions carefully. If all signers use the same compromised interface, the multisig provides no additional protection over a single-signer wallet. This is precisely what happened in the Bybit case.
Multisig wallets on Ethereum and similar networks are implemented as smart contracts. The most widely used implementation is Safe, formerly Gnosis Safe, which accounted for the majority of multisig deployments at the time of the Bybit hack. Safe’s architecture separates the signing interface from the execution logic, which should provide security through transparency. The attack exploited the gap between these layers.
Attack Vector 1: Interface Manipulation
The Bybit hack represents the most sophisticated example of interface manipulation seen to date. The attackers did not compromise the Safe smart contract itself. Instead, they injected malicious JavaScript into the Safe{Wallet} interface that Bybit’s signers used to review and approve transactions.
When Bybit’s executives opened the signing interface, they saw what appeared to be a routine cold wallet-to-warm wallet transfer. The destination address looked correct, the amount was expected, and all the details matched their intentions. But the underlying smart contract call had been altered. The actual transaction redirected over 401,000 ETH, worth $1.5 billion, to attacker-controlled addresses.
This attack works because humans verify what they see on screen, not what the smart contract actually executes. The signing interface becomes a trusted intermediary between the human and the blockchain, and compromising that intermediary completely bypasses the multisig protection.
The defense against interface manipulation is independent verification. Before signing any large transaction, use a separate, air-gapped device to verify the actual smart contract call data. Transaction simulation tools like Tenderly or Blockaid can decode the raw calldata and show you exactly what the transaction will do, independent of any user interface.
Attack Vector 2: Signer Compromise
A more direct attack vector involves compromising the individual signers themselves. In a 3-of-5 multisig, an attacker who compromises three signers gains full control of the wallet. Signer compromise can occur through various means.
Malware on a signer’s device can capture keystrokes, screen content, and even inject false information into wallet applications. A targeted phishing attack against even one signer can provide credentials that enable further intrusion into the signing infrastructure.
Social engineering attacks that trick signers into approving malicious transactions are particularly dangerous because they do not require any technical compromise. If an attacker can convince a signer that a legitimate transaction needs urgent approval, the multisig protection is bypassed with the signer’s willing participation.
The defense against signer compromise involves operational security practices for each individual signer. Each signer should operate on a dedicated, hardened machine. Signers should use hardware wallets that display transaction details on the device screen, providing a second, independent view of the transaction. Regular security training and awareness of social engineering tactics are essential.
Attack Vector 3: Supply Chain Attacks
The software and hardware that make up your multisig infrastructure can be compromised before it reaches you. Supply chain attacks target the development, distribution, or delivery of wallet software, firmware, or hardware devices.
In the context of the Bybit hack, the compromise of the Safe{Wallet} infrastructure represents a supply chain attack on the software layer. The attackers gained access to the systems that served the signing interface to Bybit, allowing them to inject their malicious code.
Hardware supply chain attacks involve intercepting and modifying hardware wallets during shipping. While no major crypto theft has been definitively attributed to hardware supply chain attacks, the theoretical risk is well-documented and security researchers have demonstrated proof-of-concept attacks.
The defense against supply chain attacks requires verifying the integrity of your entire toolchain. For software, this means pinning specific versions of wallet interfaces and verifying their checksums against official sources. For hardware, purchasing directly from manufacturers and verifying tamper-evident packaging are the primary defenses.
Some organizations go further by building their own signing interfaces from source code that has been independently audited. While this requires significant technical resources, it eliminates reliance on third-party software distribution for critical security infrastructure.
Attack Vector 4: Smart Contract Vulnerabilities
The multisig smart contract itself can contain vulnerabilities that attackers exploit. While established implementations like Safe have undergone extensive auditing, custom multisig implementations or modified versions may contain undiscovered flaws.
Delegatecall vulnerabilities, where a smart contract delegates execution to another contract, can allow attackers to execute arbitrary code in the context of the multisig wallet. Storage collisions, where different variables in the contract occupy the same storage slot, can lead to unexpected behavior that attackers can exploit.
The defense against smart contract vulnerabilities is to use well-established, thoroughly audited multisig implementations without modification. If custom logic is required, it should be implemented through separate modules that interact with the audited core contract rather than modifying the core itself.
Regular security audits by reputable firms, monitoring of security advisories for your multisig implementation, and prompt application of security patches are all essential practices.
Attack Vector 5: Governance and Process Failures
Not all multisig vulnerabilities are technical. Governance and process failures can effectively bypass multisig protections without any code-level exploit. If signers routinely approve transactions without careful review because they trust the proposing signer, the multisig degenerates into a single-signer wallet in practice.
Time pressure is a common tool for bypassing careful review. If a signer is told that a transaction must be approved urgently to take advantage of a market opportunity or address a security concern, they may skip their normal verification procedures. The Bybit attack exploited the routine nature of cold wallet transfers to reduce scrutiny.
The defense against governance failures is establishing and enforcing strict procedural requirements. Mandatory review periods before any transaction can be executed, independent verification requirements for transactions above certain thresholds, and clear escalation procedures for unusual or unexpected transactions all help maintain the integrity of the multisig process.
Rotate signers periodically and ensure that no single individual or team has control over enough signers to execute transactions independently. Regular drills and simulated attacks can help identify procedural weaknesses before real attackers exploit them.
Hardening Your Setup
Based on the attack vectors examined above, a hardened multisig configuration should include the following elements. Use diverse signing infrastructure with each signer operating on different hardware, different software, and different network connections. This eliminates single points of failure across the signing chain.
Implement mandatory transaction simulation for all transactions above a defined threshold. This provides an independent verification layer that cannot be compromised through interface manipulation.
Establish time locks that require a waiting period between transaction proposal and execution. This provides a window for independent review and allows time to detect and respond to unauthorized transactions before they are executed.
Maintain an emergency response plan that includes procedures for pausing multisig operations, replacing compromised signers, and recovering funds to new wallets if the existing configuration is suspected of being compromised.
The $1.5 billion lost in the Bybit hack was not a failure of multisig technology itself. It was a failure of the implementation, specifically the reliance on a single compromised interface for transaction verification. Multisig remains a powerful security tool, but only when implemented with an understanding of its limitations and appropriate defenses against the attack vectors that can bypass it.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Always conduct your own research before making any financial decisions.
M-of-N sounds bulletproof until you realize all N signers can be looking at a compromised UI and approving garbage transactions
exactly. the key insight from bybit is that security is a human interface problem, not a cryptography problem
bybit lost 1.5B because someone approved a transaction they couldnt read. if thats not a UX failure nothing is
0xFrontdoor.eth the real issue is that even hardware wallets display a hash for complex transactions. you literally cannot verify what you are signing
clear signing frameworks are finally arriving but its 3 years too late. transaction simulation should have been default on hardware wallets from day one
all N signers looking at a poisoned UI and clicking approve. the crypto is fine, the humans are the vulnerability
nonce_heron_ is right. the cryptography was never broken. north korea just built a fake UI that looked real enough for all signers to click approve
the fake safe wallet UI was next level social engineering. NK basically cloned the entire interface and the signers clicked through without catching it
Multisig has been the gold standard for years but nobody talks about the blind signing problem. this article finally addresses it
blind signing is the real killer. hardware wallets showing you a hash instead of the actual transaction details