Anatomy of the Bybit hack: when the UI is the exploit

The Bybit incident was not a novel smart-contract bug. It was a signing-layer attack: the kind that bypasses scanners because the exploit lives in what the operator believes they approved.

Public reporting around the February 2025 event described a path where Safe{Wallet}-related UI infrastructure was compromised so that what signers saw did not match what their keys authorized. The cold wallet controls and multisig threshold still existed. The human verification step was poisoned. Roughly $1.5B moved. The lesson travels well beyond one exchange.

This note is a field anatomy for security leads who treat "UI" as cosmetics and "multisig" as a finished control. It is not a full forensic report and it is not legal advice.

What "signing-layer" means

A signing-layer attack sits between intent and cryptography:

1. The operator intends to approve a benign action
2. The interface presents a benign summary
3. The payload that is hashed and signed authorizes something else
4. The chain (or the CA, or the deploy system) executes the signed truth

Cryptography worked. Policy thresholds may have worked. Perception failed.

The same class shows up in:

• Hardware wallet flows that trust a companion app screen
• Enterprise code-signing and release approvals
• CI/CD "approve deploy" buttons
• Privileged access brokers and PAM consoles
• Bridge guardian and treasury Safe ceremonies

If a human signs what they see rather than what the system executes, you have a signing-layer vulnerability regardless of stack.

Anatomy: where the path breaks

### 1. Trusted UI as an oracle

Operators treat the transaction preview as ground truth. Attackers treat it as a display to own. XSS, supply-chain compromise of the wallet frontend, malicious browser extensions, and poisoned DNS/CDN paths all aim at that oracle.

Control question: what independent channel confirms the hash, destination, and calldata?

### 2. Multisig without independent verification

Three-of-five does not help if all five look at the same compromised UI and the same false summary. Threshold multiplies consent. It does not multiply truth unless signers verify out of band on diverse stacks.

### 3. Cold path, warm assumptions

"Cold wallet" describes key custody temperature. It does not describe UI integrity. If the ceremony still depends on a general-purpose browser session for decoding intent, the cold label is incomplete.

### 4. Simulation and policy gaps

Transaction simulation, decoding, and allowlists only help when they run on a path the attacker does not also own. A simulator that uses the same compromised frontend is not a second opinion.

Why it matters beyond crypto

Replace "Safe transaction" with "production deploy," "wire transfer," or "certificate issuance." The failure mode is identical: a privileged human approved a summary that lied.

Enterprise examples we still see in assessments:

• Code-signing queues where the ticket text and the artifact hash are not bound
• Cloud console actions approved from a single SSO session with no step-up payload review
• Vendor payment changes confirmed only inside the same mailbox that was phished

The Bybit-scale outcome is rare. The class is not.

What we recommend as a review boundary

1. Independent verification — hash / destination / calldata checked on a second channel (hardware device screen, air-gapped decoder, printed checklist) before signature
2. Diverse signer stacks — different OS images, browsers, extensions, and network paths across the quorum; shared MDM and shared password vaults count as one stack
3. Transaction simulation on a trusted path — read-only replay that the operator controls, not only the wallet host's HTML
4. Policy allowlists — destination and selector constraints for cold paths; unexpected calls require a break-glass procedure with extra eyes
5. Operator assumptions — train that the UI is hostile until the payload is verified; ceremonies written down and rehearsed
6. Supply-chain watch on signing frontends — integrity for wallet apps, browser extensions, and CDN-hosted UIs treated as tier-0

None of this replaces contract audits or custody design. It sits above them, where the expensive failures keep landing.

Closing note

When the UI is the exploit, more cryptography on the same screen does not save you.

Teams that verify payloads out of band, diversify signer environments, and treat signing frontends as critical infrastructure find this class before a ceremony becomes a press release. Teams that trust the green checkmark on a single webpage keep rehearsing the same incident with larger numbers.

---

AN3 Intel · field notes on signing-layer risk.