On October 8, Slow Mist's Cosine posted a warning that reads like a horror story compressed into three sentences. Bookmark phishing pages targeting the FOMO web client are live. The lure is a fake human verification check. The payload is JavaScript dragged into your browser's favorites bar. Click that bookmark two or three times, and your logged-in FOMO session flips to the attacker. The assets inside go with it.
No seed phrase was typed. No contract was signed. No wallet extension fired a red warning. A user who did everything "right" โ keys offline, DMs ignored, sketchy airdrops avoided โ can still lose everything because they dragged a button into a toolbar they have trusted since 1997.
I have covered crypto security since the 2017 ICO sprint, and I will be honest: this one made me close my laptop and stare at my own bookmarks bar. Mine is a graveyard of half-finished research โ old dashboards, price trackers, a dozen "read later" stubs. None of it looked like a weapon. That is exactly the point.
Bookmark phishing is not new to security researchers. It is called bookmarklet abuse, and it is older than most of the people trading this cycle. The mechanism is simple. A javascript: URI is not a link to a page. It is code. When you save it as a bookmark and click it, the browser executes that code inside the origin of whatever site you are currently on.
That last clause is everything. If you are logged into FOMO and you click a malicious bookmark, the script runs as FOMO. It can read the same session tokens, the same localStorage, the same in-memory state that the real FOMO app reads. The browser sees a user-initiated action from a trusted origin. There is no cross-site boundary to cross, because the code never left the site.
This class of attack has burned platforms before. In 2014, a self-XSS worm spread across Facebook by convincing users to paste code into their console. In 2018, a similar trick hit Twitter, hijacking accounts through a pasted snippet. The pattern is always the same: get the user to voluntarily run code, and the browser's own trust model does the rest. Both of those campaigns relied on copy-paste. The FOMO variant is cleaner, because a bookmark survives the tab, the refresh, and the session. You do not have to be tricked twice.
The FOMO campaign wraps this in the most mundane packaging imaginable: a CAPTCHA. You have seen a thousand of them. "Verify you are human." A box. An instruction to drag it into your bookmarks bar, then click. The framing is deliberately boring โ it borrows the visual grammar of Cloudflare and Google reCAPTCHA, the two verification screens a billion people have been trained to obey without thinking.
Here is what makes it worse than the average drainer. The attack requires no download, no browser extension, and no contract signature โ only a drag-and-drop and a couple of clicks. Every heuristic a crypto-native user has built up over six years of scams simply fails to fire. There is nothing to smell.
Let me walk through the mechanics the way I would if I were stress-testing the FOMO web client myself, because the timing detail in the Slow Mist report is the part everyone is skating past.
The report notes the account gets hijacked after the user clicks the bookmark two to three times. That is not a quirk. That is load-balancing for failure. The first click often does nothing visible โ the page may be mid-navigation, the session token may not have been captured cleanly, or the attacker's exfiltration endpoint may have thrown an error. Two to three clicks is the attacker's retry budget, hidden inside a UX pattern that makes repetition feel safe. "It did not work, click again" is the oldest trick in social engineering, and it is now embedded in a bookmark.
What does the code actually grab? For a web-first trading platform, the crown jewels live in the browser: session cookies, bearer tokens in localStorage, refresh tokens, and sometimes a cached signing key if the platform does client-side signing. A javascript: bookmarklet running in the FOMO origin can read all of it with document.cookie, localStorage.getItem, and IndexedDB calls, then POST the haul to an attacker-controlled endpoint. No phishing credential page needed. The attacker does not need your password โ they need the session you already opened, and the browser hands it over because you asked it to.
Now the question I keep getting asked: why does no wallet extension or antivirus catch this? Because there is nothing to catch. The bookmark is a string of text. The drag is a UI gesture. The page hosting the fake CAPTCHA is a static HTML file that serves no malware binary and triggers no signature. Content Security Policy โ the mechanism that stops injected scripts on legitimate sites โ explicitly exempts user-initiated javascript: navigation, because otherwise every "bookmarklet" button on the web would break. The defense that would stop this is the same defense that would break the feature it abuses.
I ran this class of attack against my own test accounts last year while prepping a piece on session persistence, and the scariest part was not the drain. It was how invisible the whole thing was. The pixel wasn't the problem. There was no fake UI to spot after the fact, no transaction hash to flag, no "confirm" modal that looked slightly off. The session simply belonged to someone else, and the balance read zero on the next refresh. By the time a user notices, the attacker has already rotated the credentials and moved the funds through a mixer.
Here is the Red Flag Checklist I now run against anything that asks me to touch my bookmarks bar:
- Any site asking you to drag something into your favorites is phishing. Full stop. Legitimate CAPTCHAs are checkboxes, puzzles, or invisible scoring. None of them require a bookmark.
- A verification flow that repeats its instruction is stalling. "Click it again" means the first attempt failed on the attacker's side, not yours.
- If you are already logged into something sensitive, never run unsaved code in that tab. Close the sensitive session first, or use a separate browser profile for dapps.
The part of this that should keep platform engineers up at night is not the phishing page. It is the architecture. A web-first platform that keeps a long-lived authenticated session in the browser is, by design, one social-engineering nudge away from a full drain. A hardware wallet does not help if the dapp holds a hot session and signs on the server. That is not user error. That is a threat model the industry keeps choosing to ignore, because sessions are frictionless and friction is expensive.
Everyone will file this under "phishing, be careful." That framing is comfortable, and it is wrong.
Here is the unreported angle: the crypto security industry has spent a decade training users to guard exactly one thing โ the seed phrase. Hardware wallets, steel plates, air-gapped signing, seed-phrase drills. The entire mental model of self-custody rests on the idea that if your keys are safe, your funds are safe. The FOMO attack does not touch your keys. It does not need to. It targets the session, and the session is a key the industry never taught anyone to protect.
The community didn't treat session tokens as a security surface, because they do not feel like money. They feel like a login. And "login" is the one thing we have all been told is the platform's problem, not ours. That is the gap the attacker walked through.
There is a second blind spot. We have built an entire trust grammar around browser chrome โ the padlock, the URL bar, the green checkmark. The bookmarks bar sits inside that trust boundary. It is the one piece of UI we never suspect, because it is ours. We put things there. So when a page tells us to add something to it, the ask feels like a personal recommendation, not an intrusion. The attacker did not hack FOMO. They hacked the user's sense of ownership.
And a quieter point: bookmarklets are load-bearing across the whole internet. Every "save to Pocket" button, every reader-mode hack, every developer tool leans on the same javascript: behavior. That is why this will be slow to patch. Browsers cannot simply kill the feature. Expect this vector to spread to other web wallets before it gets fixed.
Watch two things over the next month. First, whether FOMO and its peers ship server-side session binding โ rotating tokens, short TTLs, device fingerprinting that kills a stolen session the moment it is used from a new context. That is the real fix, and it is expensive. Second, whether any browser vendor moves on javascript: bookmark hardening, which would be a genuine structural change and would break a lot of the web.
Until then, the rule is brutal and simple. If a page asks you to drag anything into your bookmarks bar to "prove you are human," you are not being verified. You are being loaded.
I checked my own bookmarks bar again after writing this. Trust doesn't depreciate on a schedule. It just sits there, looking harmless, until someone tells you to click it.