Bybit, 21 February 2025: the cold wallet moved because the signing screen lied

On 21 February 2025 Bybit was moving ether from a cold multisig wallet to a warm wallet and lost control of the cold wallet. The company's own timeline puts the transfer attempt at 14:13 UTC and the loss at about 401,347 ETH plus staked ether derivatives, together reported near 1.5 billion dollars.

The FBI said on 27 February that Lazarus Group was responsible. Sygnia and Verichains, hired by Bybit, and Safe's own statement on 26 February, agreed on the shape: a Safe developer machine was compromised, and the transaction Bybit's signers approved was not the transaction they thought they were signing.

What the forensics agreed on

Bybit's press note of 26 February says the credentials of a Safe developer were compromised and that this let the attacker deceive signers into approving a malicious transaction. Safe's statement the same day says the review did not show a flaw in the Safe smart contracts or in the source of the frontend. The malicious code was served from Safe's infrastructure, aimed at Bybit's contract.

Sygnia's interim finding, as reported that week, was that Bybit's own infrastructure did not show a compromise. Two things can be true: the exchange's servers were clean, and the screen its signers trusted was not.

Who else was in the blast radius

Safe is not a Bybit product. Other teams sign with the same wallet software. Safe said the campaign was aimed at the Bybit safe, that it rebuilt the infrastructure, rotated credentials and restored the Ethereum frontend with extra warnings. A user of Safe who was not Bybit was not automatically drained. They were using a frontend that had been in a position to lie.

Bybit said client balances stayed backed and that it covered the hole. That is a treasury decision, not a property of multisig. The ether that moved was gone from that wallet.

What this was not

It was not a broken cryptographic primitive in the Safe contracts, according to the forensic statements published on 26 February. It was a supply chain into the machine that publishes the interface, plus signers who approved what that interface showed.

Calling it 'user error' skips the half that matters to the next operator: the interface is part of the trusted computing base the moment a human compares nothing else. A hardware wallet that displays the real destination is the comparison. A browser is not.

What to change in a signing workflow

Read the destination and the amount on the device that holds the key, not only in the website that proposed the transaction. If those two screens disagree, do not sign. Prefer a publisher you pin, and treat a sudden domain or a paused frontend as a reason to wait.

For the organization: separate the people who can publish the signing interface from the people who hold the keys, keep that interface's deploy keys offline, and rehearse the call you make when the screens disagree. Safe's commitment after the incident was verifiability of transactions. That is the requirement to copy, not a vendor logo. The patching version is not a Safe contract release. Safe said on 26 February 2025 it had rebuilt its hosted infrastructure and rotated credentials. The contracts were not the piece that changed.

Bybit's 26 February 2025 statement on the Safe{Wallet} incident, and the FBI attribution reported the next day.

https://www.bybit.com/en/press/post/bybit-confirms-security-integrity-amid-safe-wallet-incident-no-compromise-in-infrastructure-blt9986889e919da8d2