In February 2025 attackers took approximately $1.46 billion in Ethereum from Bybit. It is the largest theft in the history of the asset class, and it is on this page rather than in a crypto publication for one reason: the root cause was not a smart contract bug and not a stolen private key. It was a JavaScript file on a web page that had been changed.
Bybit used Safe{Wallet} to manage the wallet in question. The attackers did not attack Bybit at all — they attacked the interface Bybit used, and waited.
Sixteen days of patience, then two minutes of cleanup
The account of the intrusion published by Sygnia and by NCC Group runs roughly as follows. On 4 February a Safe{Wallet} developer's macOS workstation was compromised through social engineering. The following day the attackers reached the AWS environment — not by defeating multi-factor authentication, but by riding a live session token that had already been through it.
Then they waited sixteen days, studying how authentication and token handling worked, before touching anything. On 21 February they modified the JavaScript in the S3 bucket serving the Safe{Wallet} web interface.
The payload contained an activation condition restricting it to one specific Bybit cold wallet. Every other user of the service was served a clean application. When the transaction was signed, the interface displayed something legitimate while what actually reached the signers' hardware devices upgraded the wallet contract to one the attackers controlled.
Two minutes after the transaction went through, they removed the code from the interface.
Any audit, scan or manual review conducted after the fact found a clean site. The malicious code existed on the page for a matter of minutes, and only for one visitor.
- The lesson of the timeline
Everything that looks at a website would have missed it
Work through the usual defences against that timeline and they come apart one by one.
A scanner visiting the site sees clean code — the payload was gone two minutes after it fired, and would not have been served to the scanner anyway. Staging and QA saw the clean application, because the activation condition excluded them. A code review finds nothing, because the change was made in the S3 bucket rather than in a repository. Multi-factor authentication was in place and was never defeated; the session it protected was simply reused.
The only place the attack was ever visible was a real browser, in the one session that mattered, during the few minutes the modified script existed. Nothing that samples, schedules or simulates was ever going to be looking then.
The honest limit, and where the signal actually is
It is worth being straight about what would and would not have helped, because the page is not worth much otherwise.
A Content Security Policy that constrains where scripts may load from would not have blocked this. The scripts came from the origin they were supposed to come from, at the URLs they had always used. No new host appeared. Nor was there any data exfiltration to catch: nothing was sent anywhere, because the theft was a transaction the user signed themselves.
Browsers already tell us the answer. With CSP Integrity, every script a real browser executes is reported to us with a content-addressed fingerprint alongside its URL — so the same address serving different code is a different fingerprint, arriving from the session where it actually ran. We keep a verified copy of each version in the JavaScript archive, which is why the question “what exactly was on the page at 14:00?” has an answer rather than a shrug.
That is the signal in this attack — a known URL, on a trusted origin, serving content it has never served before. It is also why we are building the fingerprint into Script Watch's alerting rather than leaving it as forensic record.
Why a crypto story belongs on a payments page
If you take payments rather than custody assets, the vertical is not the point and the sum is not the point. The mechanism is.
An attacker with write access to a file your checkout already loads, who serves the malicious version only to the sessions worth attacking, and who removes it afterwards, is describing an attack on any high-value transaction flow. The Bybit case is the version where somebody has published exactly how it was done, and put a number on it.
How we can help
You don't need a mature Content Security Policy to start. Script Watch gives you the inventory of what executes on your pages, Data Watch gives you the destinations receiving data from them, and CSP Integrity adds the fingerprint of each script as it ran. One line of code or config to deploy.
Reach out to sales@report-uri.com if you want a demo or a trial with no commitment.
