TL;DR

In February 2025, a supply-chain compromise of a third-party multisig service led to a $1.44B heist on Bybit.
Attackers injected malicious code into the service’s UI so Bybit’s team unknowingly approved fraudulent transfers.
Even trusted vendors can be vulnerable: every dependency should be treated as an external risk (scanned, audited, and monitored).
Protocol hardening, including thorough audits of third-party code, and stricter multi-sig defaults (timelocks, multi-step approvals), is critical to prevent such attacks.
Exploitless offers forensic analysis and runtime defenses (real-time monitoring and attack tracing) to help teams uncover and mitigate supply-chain threats.

1. The Bybit/Safe{Wallet} Supply-Chain Hack

On February 21, 2025, Bybit suffered an unprecedented attack when hackers stole approximately $1.44B in cryptocurrency. This was no ordinary hack, it was a supply-chain compromise. The attackers first infiltrated a Safe{Wallet} developer’s environment, stealing credentials and server access. Essentially, they took control of the third-party multisig service Bybit used for cold-wallet withdrawals.

With that access, they tampered with the client-side approval logic. Security reports indicate the attackers injected malicious code into the Safe{Wallet} web interface. When Bybit’s staff went to approve a routine transfer, the UI showed the expected cold→hot withdrawal, but the underlying transaction was secretly rewritten to an attacker-owned address. The signatures still verified correctly, so the blockchain executed the transfer, transferring ~401,000 ETH (about $1.44B) to the hackers.

Key Insight: This breach highlights that the vulnerability was off-chain. Lunaray’s analysis specifically notes that attackers “bypassed multi-factor authentication and transferred assets by tampering with the code logic of third-party multi-signature services”.

In practice, the operators checked the on-screen numbers, but by the time the multisig transaction hit the blockchain, it was maliciously altered.

Bybit’s immediate response was to pause withdrawals and cover the loss with its own funds.

It also announced a switch of vendors and tighter audits. But this incident underscores a sobering lesson: no external component should be implicitly trusted, even if it’s a core service.

2. Anatomy of the Tampering

In simple terms, the hack exploited blind spots in the multi-sig approval chain. The attackers manipulated a trusted interface to fool the signers. For example:

Developer Compromise: The attackers first planted malware on the Safe{Wallet} developer’s machine (e.g. disguised as a fake app). This gave them keys to Safe’s cloud and code repository.

Code Injection: Using that access, they altered the multisig frontend code. They inserted a snippet that switched the transaction’s destination to the attacker whenever Bybit signed a transfer.

Stealth Approval: When Bybit’s engineers submitted a cold-wallet transfer, the modified UI displayed the expected address. Behind the scenes, however, the malicious script replaced it with the attacker’s wallet. The transaction was then signed and sent.

Execution: On-chain, the transaction looked valid: sufficient signers, correct payload format. The network moved the funds, but they ended up in the hacker’s control.

Because this trickery happened outside the blockchain, the usual smart-contract checks couldn’t stop it. Even an on-chain security audit wouldn’t catch a UI change. The blockchain simply saw a legitimate multisig execution. The takeaway: when you rely on a vendor’s software or interface, treat every update as potentially adversarial.

3. Strengthening Multi-Sig and Supply-Chain Defenses

There are concrete steps to harden your protocol against these threats:

Audit Third-Party Code: Don’t assume vendor software is safe. Include it in security reviews. If possible, inspect the multisig service’s source code, and monitor its deployments. For instance, setting up alerts on changes to the Safe{Wallet} frontend could have flagged the injected script.
Time-Locks and Delays: Insert intentional delays on large transfers. A simple pattern is to queue an approved action for 24–72 hours to allow extra review.

For example:

uint256 public constant DELAY = 48 hours;
   mapping(bytes32 => uint256) public queuedActions;
   function queueAction(bytes32 actionId) public onlyMultisig {
   queuedActions[actionId] = block.timestamp + DELAY;
   }
   function executeAction(bytes32 actionId) public onlyMultisig {
   require(block.timestamp >= queuedActions[actionId], "Time-lock not expired");
   delete queuedActions[actionId];
   // perform the critical transfer…
 }

This snippet ensures every signed transaction waits for the delay, giving time to spot anomalies (e.g. a sudden new recipient).

Two-Step Transfers: Require a second confirmation before transfers are final. For example, one key can propose a transfer, but a different key must confirm it. This is similar to the “two-step ownership transfer” pattern: one party sets a pending recipient, and the other must call an accept function. In practice, this means even if a malicious script proposes a transaction, it can’t be fully executed without an independent sign-off.
Role Separation: Divide responsibilities so no single person or system has unchecked power. For example, the team that schedules transfers could be separate from the team that approves them. The more distinct checks you have, the harder it is for a single point of failure.
Out-of-Band Verification: Whenever possible, verify transfer details through a separate channel. This could be a hardware wallet display, a dedicated audit of transaction data, or even a secondary approval app. Human eyes on a printed or isolated version of the transaction can catch mismatches.
Continuous Monitoring: Deploy real-time watchers on-chain. Alerts can trigger if unusually large transfers are initiated or if funds start moving to unfamiliar addresses. Automated anomaly detection can pause or rollback actions if red flags appear.
Least Privilege: Limit what each component can do. For example, don’t give a vendor account blanket permission to alter all transactions; constrain it to minimal-needed functions. Reducing blast radius means a single compromise has smaller impact.

Combined, these measures rebuild trust in the transaction flow. The core lesson is “trust but verify.” Treat every third-party tool as potentially compromised and build in oversight. Lunaray’s report makes this clear: the Bybit loss happened because the multisig logic was silently altered. Going forward, every multisig integration or upgrade should assume the worst-case, then use code and operations to mitigate it.

4. Working with Exploitless: Forensics and Defense

At Exploitless, we guide teams through exactly these threats. Our audits cover not only smart contracts but the full stack, including any vendor libraries, wallet interfaces, or off-chain services. If you integrate an external multisig or oracle, we’ll review it just as rigorously as your own code.

Our incident response experts specialize in blockchain forensics. In a supply-chain breach, we trace every transaction hop: following stolen funds, identifying known attacker patterns (like DPRK-linked mixing chains), and correlating on-chain data with off-chain logs. In other words, we help reconstruct exactly how the attack unfolded and recover what we can.

Simultaneously, our engineers build real-time defenses into your deployment. We set up monitors on your multisig wallets that alert if a transaction’s details suddenly change, and implement on-chain invariants and circuit breakers. These tools act as an extra safety net, catching anomalies immediately, rather than after the funds have flown away.

Ultimately, we help you turn a devastating heist into a learning opportunity. By combining thorough audits, continuous monitoring, and fast incident analysis, we give you the tools to withstand and quickly respond to the most sophisticated attacks.

Learn how we work at Exploitless

References:

. Lunaray Security Report 2025; (https://lunaray.medium.com/2025-blockchain-security-situation-annual-report-b32df8d74204)

. OpenZeppelin secure patterns (two-step, timelock). (https://medium.com/@exploitless/unveiling-access-control-exploits-why-they-top-web3-hack-lists-year-after-year-19bb0bb3a43d)

Analyzing the Bybit Hack: Lessons in Supply Chain Security