On February 21, 2025, Bybit lost approximately $1.5 billion after an attacker compromised a Safe{Wallet} developer's machine through social engineering. The attacker injected malicious JavaScript into Safe{Wallet}'s AWS S3 bucket, targeting Bybit's transactions specifically. The injected code altered transaction content during the signing process: the Safe{Wallet} UI displayed a legitimate transaction, while the actual payload sent to the signers' Ledger devices upgraded Bybit's Safe contract to a malicious implementation, giving the attacker full control. Once signed and executed, the attacker drained all assets from the contract. A detailed technical breakdown is available in our earlier report [1].

Background

Safe{Wallet} (a.k.a. GnosisSafe) is a multisig wallet infrastructure using an n-of-m model: executing a transaction requires at least n signatures from m total signers.

Each Safe wallet is deployed as a proxy contract. Two storage variables are central to this incident:

• masterCopy (slot 0): the address of the implementation contract. This contract contains all execution logic, including signature verification and upgrade mechanisms. The proxy delegates all calls to masterCopy via delegatecall.
• threshold (slot 4): the minimum number of signatures (n) required. For Bybit's Safe, this was 3.

Because the proxy uses delegatecall, any function called on masterCopy executes in the proxy's storage context. This means a delegatecall target can directly overwrite masterCopy at slot 0, replacing the entire implementation in a single transaction.

Vulnerability Analysis

The attack path traversed three layers of the system, each presenting a structural condition that the attacker leveraged:

Frontend serving model. The Safe{Wallet} frontend JavaScript was served from an AWS S3 bucket. In this architecture, anyone with write access to the bucket can modify the code that constructs transactions for signers. Integrity verification mechanisms such as subresource integrity (SRI) hashes or code signing can mitigate this risk, but they are not yet standard practice for most dApp frontends. The attacker gained write access through the compromised developer machine and silently modified the served JavaScript.

Gap between UI display and signing payload. The injected JavaScript displayed a legitimate-looking transaction on the Safe{Wallet} UI while sending a different payload to the Ledger hardware wallets. The transaction details shown on the Ledger screen would have differed from the UI, but interpreting raw transaction data on a hardware wallet screen is not straightforward, especially for complex multisig operations. This gap allowed the attacker to collect three valid signatures for the malicious payload.

Proxy upgrade model. As described in Background, delegatecall executes the target's code in the proxy's storage context. The Safe proxy architecture routes all calls through a single masterCopy pointer at slot 0. Overwriting this pointer redirects the proxy to an entirely different implementation, including its signature verification logic, in a single transaction. The n-of-m model governs who can initiate a transaction, but once a transaction is approved and executed, it can alter the implementation itself. If the new implementation removes signature verification, the multisig protection is effectively gone for all subsequent transactions.

Attack Analysis

The attack proceeded in three steps: Malicious Code Injection, Implementation Replacement, and Asset Theft.

Step 1: Malicious Code Injection

The attacker compromised a Safe{Wallet} developer's machine and injected malicious JavaScript into the AWS S3 bucket serving the frontend. The injected code specifically targeted transactions from Bybit's Safe address. According to Bybit CEO Ben Zhou [2], the Safe{Wallet} UI displayed a legitimate transaction, while a different payload was sent to the signers' Ledger devices. The signers approved the transaction as presented in the UI, giving the attacker three valid signatures for the malicious payload.

Step 2: Implementation Replacement

The attacker submitted the malicious transaction with the three collected signatures. The Safe proxy delegated the call to masterCopy, whose execTransaction() validated the signatures and then executed the transaction payload: a delegatecall to the attacker's contract (0x962214...5c7242). Because this delegatecall runs in the proxy's storage context, the attacker's transfer() function overwrote the value of masterCopy at slot 0 with a malicious implementation address (0xbDd077...9516). From this point on, all calls to the Safe contract were delegated to the attacker's code.

Step 3: Asset Theft

With masterCopy now pointing to the attacker's implementation, the multisig requirement no longer applied. The attacker called SweepERC20() and SweepETH() directly on the Safe contract. These functions, defined in the attacker's implementation contract, transferred all held assets without any signature verification. Five drain transactions were executed, totaling approximately $1.5 billion in losses.

Related Contracts and Transactions

Summary

This incident demonstrated how a compromise of off-chain infrastructure can cascade into catastrophic on-chain losses. The attacker chained a Web2 breach, a frontend manipulation, and a proxy upgrade into a single attack path that bypassed multisig protection without exploiting any on-chain vulnerability.

Key lessons:

• Frontend integrity deserves the same attention as on-chain security. The attack chain began at the frontend serving layer. As dApps increasingly mediate high-value transactions, protecting frontend code with integrity verification (SRI, code signing, reproducible builds) and monitoring for unauthorized changes becomes a baseline requirement.
• Hardware wallet verification remains difficult in practice. Hardware wallets can display the actual signing payload, but interpreting complex multisig transaction data on a small screen is a known usability challenge. Improving the readability of on-device transaction summaries is an open problem for the wallet ecosystem.
• Proxy upgrade mechanisms are high-leverage targets. The Safe proxy architecture routes all logic through a single upgradeable pointer. Any mechanism that allows a one-step implementation replacement concentrates risk. Adding a timelock, a secondary confirmation step, or an independent guardian for upgrades can reduce the impact of a single compromised transaction.

Reference

1. BlockSec: Bybit $1.5B Hack In-Depth Analysis

2. Bybit CEO Ben Zhou X Broadcast

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.

• Official website: https://blocksec.com/

• Official Twitter account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Submit a request

• 🔗 Phalcon Security APP: Book a demo

• 🔗 Phalcon Compliance