A browser bookmark should be the most inert object in your digital life. It is a URL. A pointer. A saved address. It cannot execute. It cannot sign. It cannot move funds.
That assumption is now dead.
In the same week most desks were staring at funding rates and liquidation heatmaps, SlowMist's Yu Xian published a short, quiet disclosure that deserved a much louder alarm. A Web3 web platform called FOMO had been hit by a phishing campaign that did not touch its smart contracts, did not drain a liquidity pool, and did not exploit a single line of Solidity. The attackers instead convinced users to save a piece of malicious JavaScript as a browser bookmark. Then they waited for the user to click it two or three times inside a logged-in FOMO session. When the user complied, the code executed in FOMO's own origin context, hijacked the session, and emptied the account.
The block does not lie. But it did not care, either — because the theft never touched the chain in any way that mattered. The signature that emptied these accounts was not a transaction. It was a click.
The most dangerous code in crypto right now is not on-chain. It is sitting quietly in your bookmarks bar, waiting for you to trust it.
Context: The Disclosure, the Platform, and the Blurry Line
Let me establish the baseline before I isolate the deviation, because this event has been mislabeled in at least half the coverage I have read.
FOMO is an application-layer Web3 platform. The name — fear of missing out — tells you almost nothing useful; it could be a trading interface, a social layer, a gamified launchpad, or a custodial account system. What matters is the architecture the disclosure implies, not the branding. SlowMist's report references a "logged-in FOMO account" and an asset balance that could be "immediately stolen." That language is precise, and precision is where the story lives. A pure non-custodial wallet cannot be emptied by a bookmark, because there is nothing to empty — the keys sit in an extension or a hardware device, and a same-origin script in a web tab cannot reach them without an explicit signature. A custodial or semi-custodial web account, by contrast, holds a session token that is functionally a bearer instrument. Steal the token, and you are the user. The platform cannot tell the difference, because structurally there is no difference.
SlowMist itself occupies a specific ecological niche here. It is not the victim, not the attacker, and not the regulator. It is the immune system — a security firm whose disclosure function is itself part of Web3's infrastructure. When a firm like SlowMist issues an early warning, it is performing a service that has no clean Web2 equivalent: real-time, community-facing threat intelligence. This is the ecosystem's central irony. The same industry that preaches "code is law" and "don't trust, verify" relies on a handful of centralized security firms to tell it, after the fact, that the law had a hole in it.
The disclosure is also, notably, single-source. There is no second firm cross-validating the mechanism, no on-chain forensics published yet, no victim tally. That does not make it wrong. It makes it unconfirmed, which is a different category — and one I will return to when I separate signal from noise.
So here is the frame. A social-engineering attack, delivered through a legitimate browser feature, exploiting a session layer that contract auditors never inspect, against a platform whose custody model we can only infer. Every one of those clauses is load-bearing. Remove any of them and the story collapses into ordinary phishing. Keep them all, and you have something that exposes a structural blind spot in how this entire industry spends its security budget.
Core: The Attack Chain, Reconstructed
The Mechanism, Step by Step
The disclosed chain is short enough to hold in one breath, which is exactly why it is dangerous. A fake human-verification page — a counterfeit CAPTCHA — is presented to the user. The page does not verify anything. It instructs the user to drag a snippet of JavaScript into their bookmarks bar, framed as a "security check" or a "verification step." The user complies. The malicious code is now saved as a bookmarklet. Later, while logged into FOMO, the user is prompted to click that bookmark two or three times. On execution, the JavaScript runs inside FOMO's own origin — the same domain, the same context, the same trust boundary as the legitimate application — reads the session, and initiates the asset transfer.
That is the whole thing. No zero-day. No memory corruption. No reentrancy. No oracle manipulation. A social-engineering lure, a browser feature used as designed, and a session that trusted its own origin a little too completely.
I want to dwell on the elegance of the primitive, because elegance is what makes attacks scale. A bookmarklet is not malware in the traditional sense. It is not installed. It is not compiled. It does not persist in a process. It does not appear in an extensions list, does not require a permission prompt, and does not trigger the browser's malware heuristics in most configurations. It is a string of text the user voluntarily saved. The attack surface is not the platform's code. The attack surface is the user's willingness to follow instructions.
Why the Same-Origin Context Is the Entire Game
Here is the technical heart of the matter, and if you take one thing from this piece, take this.
Modern web security rests on the same-origin policy. Code served from fomo.example can read the DOM, cookies, and session storage of fomo.example. Code from evil.example cannot. The entire architecture of browser trust is built on this boundary. A bookmarklet breaks the model in a specific and uncomfortable way: it executes in the context of whatever page the user is currently viewing. Click the bookmark while you are on FOMO, and the code runs as FOMO. The origin boundary is not breached. It is borrowed.
This is why the attack is so hard to defend against from the platform side. A Web Application Firewall inspects traffic. Here, there is no anomalous traffic — the request that reads the session and the request that initiates the transfer both come from the legitimate user's browser, over a legitimate connection, with a legitimate token. A risk engine that scores transactions by IP, device fingerprint, and behavioral pattern sees a user who is already authenticated performing an action. The only anomaly is intent, and intent is not in the packet.
Content Security Policy is the one control that could meaningfully interfere, and its effectiveness here is conditional. A strict CSP that forbids inline script execution and restricts script-src to trusted origins can neutralize a bookmarklet that relies on injected inline code. But most Web3 front-ends are built on frameworks that lean on inline scripts, dynamic evaluation, and third-party widgets — analytics, wallet connectors, session managers. Tightening CSP to the point of blocking a bookmarklet usually means breaking half the application. The teams that get this right treat it as a first-class engineering discipline. Most do not. This event is the receipt.
The "Two or Three Clicks" Detail
Most readers will skim past the phrase "clicked the bookmark two or three times." I did not. In my experience, when a disclosure specifies a click count, that count is a clue, not a rounding error.
Three readings fit the evidence. First, the attack may be staged: the first click loads a loader or establishes a channel, the second triggers the read, the third confirms or retries. Staging defeats single-event detection and gives the attacker a fallback if one step silently fails. Second, the first click may be a decoy — a harmless-looking action that builds the user's confidence, so that the second, malicious click arrives when the user has stopped being suspicious. Third, the sequence may simply be waiting on session state: the attacker needs the user to be fully authenticated, with a live token, before the payload is worth firing. Under this reading, the clicks are not steps in a program so much as a handshake with the session.
I cannot resolve which of these is correct from a single-source disclosure, and I will not pretend otherwise. But the inference matters: a multi-click sequence implies a designed attack with an operator behind it, not a scraped script fired blindly. Someone tuned this. Someone tested it. Someone measured conversion.
The Custodial Inference — and Why It Changes Everything
Follow the asset. If FOMO were fully non-custodial — keys held by the user, in the user's wallet — a session hijack would not be sufficient to "immediately steal" assets. The attacker would need a signature. They would need the user to approve a transaction, or they would need a pre-signed allowance the user had already granted. A same-origin script can initiate a signature request, but it cannot forge the cryptographic proof.
The disclosure says assets were taken immediately. That points, with medium confidence, toward a custodial or semi-custodial architecture — a platform that holds a session and, behind it, holds the ability to move user assets. If that inference is correct, then the phrase "the platform was attacked" is doing a lot of quiet work. What was actually attacked was a user's session on a platform that had taken custody of that user's assets. Those are not the same claim, and the difference is where legal liability lives.
I flag this with the confidence it deserves — medium, not high. The disclosure does not name the custody model, and I will not invent one. But the logical constraint is tight: immediate theft plus session-only access equals custody, or something close to it.
The Audit Budget Mismatch
Here is where my own history becomes relevant, because I have spent the better part of a decade inside this exact misallocation.
In 2017, as a junior quant at a boutique London fund, I spent forty hours manually verifying the elliptic-curve pairing logic in Zcash's initial shielded-transaction protocol. I cross-referenced the G1/G2 point calculations against my own Python scripts and found three implementation inefficiencies before the public audit did. The lesson I took from that work was not that audits are useless. It was that verification is a discipline of choosing the right surface. I verified the mathematics because the mathematics was where the value lived.
That instinct is exactly what is broken industry-wide today. The overwhelming majority of Web3 security spend flows toward smart-contract auditing — reentrancy, integer overflow, access control, oracle manipulation. These are real problems. They are also increasingly well-understood problems, with mature tooling, established firms, and a public track record. The marginal dollar spent on the twentieth contract audit of a codebase buys very little new safety.
Meanwhile, the front-end and session layer — the layer where this attack lives — receives a fraction of that attention. It is not audited by the firms that audit contracts. It is not modeled in the threat frameworks that dominate the conversation. It is treated as a UX concern rather than a security boundary. The industry has optimized the surface it knows how to measure and neglected the surface that is actually being exploited.
This is a classic measurement artifact. We audit contracts because contracts are auditable — discrete, static, bounded. We neglect the browser because the browser is messy, stateful, and spans the boundary between platform and person. The attack did not happen where we were looking. It happened where we assumed nothing could go wrong.
Self-XSS and the User-as-Executor Problem
There is a precise name for the class of attack this belongs to: self-XSS. The defining feature is that the victim executes the malicious code themselves. The attacker never injects anything into the platform. They do not need to. They convince the user to inject it.
This is the reason no amount of platform-side hardening fully solves the problem. You can build the most rigorous front-end in the industry, and a user who has been socially engineered into pasting code into a console or clicking a saved bookmark will still hand you the keys. The final control surface is the user's judgment, and judgment is not patchable.
But that is a lazy conclusion, and I refuse to stop there. "Users are the weakest link" is true and useless. The useful question is: what made this particular social engineering so effective, and what does that tell us about the platform's responsibility? The lure was a fake human-verification page — a CAPTCHA. That is not an accident. CAPTCHAs are the one interaction where users are culturally trained to follow arbitrary, slightly weird instructions without asking why. "Drag this into your bookmarks bar" is bizarre, but "complete this verification step" is familiar. The attacker borrowed the trust of a ubiquitous interface and spent it on a malicious payload.
A platform that wants to defend against this must therefore treat its own users' instructions as an attack vector. That means session binding to devices, short token lifetimes, re-authentication for asset movements, and — most importantly — an out-of-band confirmation channel for any transfer. If a transfer requires a confirmation the same-origin script cannot reach, the bookmarklet's leverage collapses. The attack works because the session is a single point of authority. Break the single point, and you break the attack.
The Concentration of Attack Surface
I have seen this pattern before, in a different costume.
In 2021, during the NFT mania, I declined to buy blue-chip art and instead ran wallet-clustering analysis on the Bored Ape Yacht Club. The finding was uncomfortable: roughly 40% of the apparent "whale" wallets traced back to a handful of controlling entities. The floor was not a market. It was a concentration. When the floor cracked in early 2022, I had already structured a hedge because the fragility was visible in the ownership graph long before it was visible in the price.
The parallel here is structural, not coincidental. Just as a small number of wallets controlled the perceived depth of the NFT market, a small number of trust boundaries control the security of the entire Web3 front-end layer. The session token is one such concentration. The browser's same-origin policy is another. When an attacker finds a primitive that turns a legitimate feature into a weapon, the concentration that was invisible during calm becomes the single point of failure during stress.
I have built my entire methodology around hunting that kind of concentration — first with the Uniswap V2 scraper I wrote in 2020 to catch oracle-lag arbitrage, later with the modular-blockchain analyses I ran in 2022 when I calculated a 90% cost reduction for rollup sequencers on Celestia's data-availability sampling versus Ethereum calldata. In every case, the edge came from finding a hidden dependency — a lag, a bottleneck, a shared assumption — that the market had priced as if it were not there. The FOMO attack is the same shape. The hidden dependency is the session. The market priced it as free. It was not free.
Contrarian: Correlation Is a Ghost; Causality Is the Code
The reflex reaction to this disclosure is already forming, and I want to name it before it hardens into consensus. The reflex says: this is just phishing. Users clicked something they shouldn't have. Not the platform's fault. Not a systemic issue. Move on.
There is a real truth buried in that reflex, and a real error.
The truth: self-XSS is genuinely user-triggered. The platform did not leak a key. The chain did not fail. No contract was exploited. If you want to assign blame by the most literal causal chain, the user executed the code.
The error is the leap from "user-triggered" to "not a systemic issue." That leap confuses correlation with causation and then weaponizes the confusion. Yes, the user's click is correlated with the loss. But the cause of the loss is an architecture in which a single same-origin session holds unilateral authority over assets, with no out-of-band confirmation and no meaningful resistance to client-side code. The click was the trigger. The architecture was the vulnerability. Confusing the trigger for the cause is how an industry convinces itself that nothing needs to change.
There is a second, subtler error, and it concerns the disclosure itself. Single-source reporting is a signal, not a verdict. SlowMist's word carries weight, but it is one firm, and no cross-validation has been published. I am treating the mechanism as credible and the details as provisional. Anyone who treats an unconfirmed disclosure as settled fact is doing exactly what they accuse the hype cycle of doing — letting narrative outrun evidence.
And there is a third error, the one that matters most for where this goes. The reflex assumes the attack is bounded — a one-off against one platform. The mechanism says otherwise. A bookmarklet attack requires no platform-specific vulnerability. It requires a lure, a session, and a user. Every custodial or semi-custodial Web3 platform with a logged-in account and a browser front-end is a candidate. This is not an incident. It is a template. The question is not whether FOMO was uniquely careless. The question is how many other platforms share the exact same single-point-of-authority session and simply have not been targeted yet.
Takeaway: The Signal to Watch Next Week
Forget the price of anything. The signal worth tracking is behavioral and structural, and it resolves on three fronts.
First, watch whether a second platform discloses a similar attack. One bookmarklet incident is a crime. Two is a campaign. Three is a Phishing-as-a-Service product, and that changes the threat level for the entire application layer.
Second, watch FOMO's response. Whether it discloses transparently, compensates users, and ships out-of-band transfer confirmation will tell you more about its governance maturity than any whitepaper. Silence is a signal too.
Third, and most urgently, open your own browser and look at your bookmarks bar. If there is anything in it you cannot account for, delete it now. Panic is a signal; liquidity is the truth — and so is a saved URL you did not save yourself.
The block does not lie. But it also will not warn you. That part has always been your job.
