On October 8, a security researcher known as Cosine, working with the blockchain security firm Slow Mist, published a warning that most people scrolling through their feeds would have missed. It concerned something almost embarrassingly small. Not a stolen seed phrase. Not a compromised private key. Not a zero-day lurking inside a smart contract that had already passed three independent audits. A bookmark. The kind of thing we save without thinking, the kind of thing we forget we even own.
The mechanism, as Cosine described it, carries the particular elegance that all effective attacks share. A phishing page, dressed in the bland costume of a routine "human verification" gate, instructs the visitor to drag a button into their browser's favorites bar. What the visitor is actually dragging is a bookmarklet โ a sliver of JavaScript wearing the disguise of a bookmark. They save it. Some time later, with their FOMO web session still warm and authenticated, they click it. Twice. Perhaps three times. And then the account is gone โ the session hijacked, the assets swept, the door left quietly open behind them.
I have spent enough years reading incident reports to know that the smallest vectors often carry the heaviest consequences. This one deserves more than a retweet. It deserves a slow reading. Before the storm breaks, the air changes, and this is one of those changes.
To understand why this attack works โ and why it will keep working โ you have to travel back to a feature that predates almost everything we now call "Web3." In 1995, Netscape Navigator introduced a small, almost accidental capability: the ability to save a snippet of JavaScript as a bookmark. The javascript: URI scheme, as it came to be known, let a user store a piece of executable code in the same place they stored their favorite websites. These were called bookmarklets, and for a generation of power users they were a quiet superpower โ a way to resize images, strip paywalls from reading views, translate pages, or automate small annoyances without installing an extension.
The feature was never designed with security in mind, because in 1995 there was no meaningful notion of a "web application" holding your money. Bookmarklets were toys for tinkerers. The web was a library, not a bank.
The decades since have been a slow, uneven migration of value into the browser. Email phishing gave way to credential phishing, then to session phishing, then to the click-based delivery we see here. Each generation of attack learned from the defenses of the last. When filters learned to catch malicious attachments, attackers moved to links. When browsers learned to flag bad links, attackers moved to social engineering. And when users learned to distrust links, attackers moved to gestures โ dragging, copying, pasting, clicking. The FOMO bookmark attack is the logical endpoint of that arms race: an attack that requires no link to be trusted, no file to be opened, and no download to be approved. It asks for a drag, and a drag feels like nothing.
That assumption about the web being a library died a long time ago. Today, the same browser you use to read the news also holds the session cookies for exchanges, wallets, and decentralized applications. The library and the vault became the same room. And bookmarklets โ a thirty-year-old convenience โ inherited a privilege that no modern security model would ever grant if it were designed from scratch. This is the part of the story that is easy to skip past, and it is the part that explains everything that follows. The vulnerability is not in the code. The vulnerability is in the inheritance.
Here is the crucial detail that makes the FOMO attack possible. When you click a bookmarklet, the JavaScript inside it does not run in some isolated sandbox. It runs in the context of the page you are currently viewing. If that page is your logged-in FOMO session, the bookmarklet executes with the full authority of that session. It can read the page. It can call the page's internal functions. It can reach into the same-origin storage, the DOM, the authenticated API endpoints. From the browser's point of view, it is not an intruder. It is you.
This is the same-origin policy behaving exactly as specified โ and that is the horror of it. The browser is not broken. The browser is doing precisely what it was built to do. The trust was placed in the wrong hands, and the browser has no way to know that the hands are not yours.
Now consider the context of FOMO specifically. FOMO is a web-facing crypto application โ the sort of product that lives in a browser tab, authenticates you with a session, and then holds your balance, your positions, your ability to move value. The convenience is the point. You log in once, and the app remembers you. That memory โ the session โ is the asset the attacker is hunting. Not your seed phrase, which is hard to extract. Not your hardware wallet, which is offline. The session. The soft, frictionless, always-on proof that the server already believes you are you.
I want to pause on how radical that shift is. For most of the industry's history, the security conversation has been about keys. Seed phrases on steel plates. Air-gapped devices. Multi-signature schemes. The key was the crown jewel, and we built an entire culture of paranoia around protecting it. But the FOMO attack bypasses the crown jewel entirely. It walks in through the front door, while you are standing there, wearing your face, using your login. It is a reminder that the most dangerous moment in a user's security is not when they are storing value. It is when they are using it.
Let me walk through the anatomy of the attack as a security engineer would, because the precision matters. The attack has four movements, and each one is designed to defeat a specific layer of defense.
The lure. The victim arrives at a phishing page โ often through a poisoned search result, a compromised social account, or a sponsored link โ that presents a "human verification" challenge. The visual language is deliberately familiar: the CAPTCHA-like framing, the "verify you are human" instruction, the sense of a routine checkpoint. The genius of the lure is that it inverts a security ritual. Users have been trained to expect verification. The attacker weaponizes that expectation. Every legitimate site on the internet has taught you to solve a puzzle to prove you are real. This page simply asks you to prove it a different way โ and the difference is the trap.
The delivery. Instead of asking the user to type a code or solve a puzzle, the page instructs them to drag a button โ labeled innocuously, perhaps "Verify" or "I am human" โ into the bookmarks bar. This is the pivot. What the user believes they are doing is completing a verification. What they are actually doing is installing an executable bookmark. The act of dragging feels tactile and harmless, like moving a file. It is, in fact, the moment malware is written to persistent storage โ the browser's own bookmark database.
There is a name for this family of techniques in the security literature โ click-based social engineering, sometimes filed under the broader umbrella of "clickfix" campaigns. The pattern is consistent across the variants: the attacker does not try to break the machine. The attacker asks the human to operate it on their behalf. The clipboard attack, in which a victim is tricked into pasting a malicious command into a terminal, is a close cousin. The bookmark attack is a cousin with better manners โ it comes dressed as verification, and verification is a ritual we have all been conditioned to perform without thought.
The dormancy. The malicious bookmarklet sits quietly in the favorites bar. It does nothing. It waits. This dormancy is critical, because it decouples the moment of infection from the moment of theft. Anti-phishing tools that scan pages in real time see nothing after the initial drag. The user's own suspicion, if any, has time to fade. The payload is patient, and patience is the one quality most defenders do not model.
The execution. Days or hours later, the user โ now logged into FOMO, perhaps mid-transaction โ clicks the bookmark. The malicious JavaScript springs to life inside the authenticated session. This is where the "two to three clicks" detail from Cosine's report becomes significant, and I want to examine it carefully because it hints at the payload's internal logic.
Why would an attack require multiple clicks? A single well-crafted bookmarklet could, in principle, exfiltrate a session token or fire a transfer request in one shot. The fact that the reported attack needs two or three invocations suggests one of several mechanisms. It may be that the payload is staged โ the first click establishes a channel or fingerprints the environment, the second extracts and transmits, the third confirms or cleans up. It may be that the attacker is exploiting a rate limit or a confirmation step within FOMO's own interface, using repeated execution to satisfy a multi-step approval flow. Or it may simply be that the payload is designed to survive partial failure, retrying until the session's assets are fully drained.
Whatever the precise internal reason, the multi-click requirement reveals something important about the attacker's model. The attacker does not need the user to be careless once. The attacker needs the user to be careless a few times, in the ordinary flow of using their own tools. The bookmark becomes furniture. You click it the way you click anything in your bar โ reflexively, without reading. And every click that does nothing visible trains you to click again. The attacker is not exploiting ignorance. The attacker is exploiting habituation, which is far more reliable.
Now let me address the defense that should have stopped this, and didn't. Content Security Policy, or CSP, is one of the strongest tools a web application has against script injection. A well-configured CSP tells the browser which sources of JavaScript are allowed to run. It is the wall that stops most cross-site scripting attacks cold. And yet CSP is structurally unable to stop a bookmarklet.
The reason is subtle and worth stating plainly. CSP governs scripts that a page loads. It does not govern scripts that the user personally initiates. A bookmarklet is invoked by a human gesture โ a click on the favorites bar โ and the browser treats it as a trusted, user-level action rather than a page-level resource. The policy is bypassed not through a vulnerability but through the definition of the feature. This is why I insist that bookmark phishing is not a bug you can patch in the traditional sense. It is a property of the platform.
This distinction matters enormously for how we respond. If the attack were a CSP bypass, the fix would be a header, a configuration change, a patch pushed overnight. Because the attack rides on a legitimate browser feature, the fix has to be architectural or behavioral โ and both are slower and more expensive than a header. The industry prefers fast fixes. This attack refuses to offer one.
There is a useful comparison to draw here. Over the past several cycles, we have watched session-hijacking mature as a discipline. The theft of cookies โ those small tokens that stand in for your authenticated identity โ has become an entire underground economy. Attackers do not crack passwords anymore when they can steal the proof that you already typed one. Malicious browser extensions harvest sessions at scale. Infostealer malware, sold cheaply on the same forums where drainers are traded, does the same work with more reach. The FOMO bookmark attack is a new entry in an old catalog โ a session-theft technique that requires no install, no malware binary, and no elevated permission. It requires only a gesture you have been trained to perform.
Then there is the endpoint of the attack: the drain. Once the bookmarklet has the session, the actual theft is almost an afterthought, because the tooling for it is mature. Wallet drainers โ the industrial-grade frameworks that have been refined over several market cycles โ do not need to break cryptography. They simply use the access they have been handed. They enumerate the assets the session can reach, they construct the transfer transactions, and they route the value outward through a network of intermediate addresses and mixers designed to frustrate tracing.
I have audited enough of these flows to know the pattern by heart. The victim's funds move in a burst โ often within seconds โ split across multiple hops, then consolidated, then pushed through a bridge or a privacy service. By the time the victim refreshes the page and sees a zero balance, the money is already several layers away, and the recovery rate for these incidents is brutally, almost mathematically, low. Chain analysis helps. It rarely restores. This is the asymmetry that defines crypto security: the attacker needs one successful session, and the defender needs to prevent every one, forever.
The economics explain the persistence. A phishing kit of this kind is cheap to produce and infinitely reusable. The phishing page is a template. The bookmarklet is a script. The drainer is a service. Nothing in the chain requires bespoke engineering for each victim, which means the marginal cost of an additional theft approaches zero. When the cost of an attack falls that low, the attacker does not need a sophisticated target. The attacker needs volume โ and volume is exactly what a mass-market web wallet provides. The FOMO user is not targeted because they are valuable. The FOMO user is targeted because they are many.
Let me bring in something from my own experience, because abstract threat modeling has a way of numbing the reader. In 2022, during the winter that followed the Terra collapse, I spent two months deliberately away from public discourse, auditing the narrative and the mechanics of how centralized systems fail their users. One of the things I learned in that silence is that the most damaging exploits are rarely the most sophisticated ones. They are the ones that exploit a trust we did not know we were extending.
The FOMO bookmark attack is a perfect specimen of that category. It does not attack the blockchain. It does not attack the smart contract. It attacks the seam between the user and the browser โ a seam that thirty years of web design has taught us to ignore. We were taught that the bookmarks bar is ours, a private shelf of things we chose. The attacker rented that belief and used it as a delivery vehicle. Decoding the whisper before it becomes a shout means recognizing that the surfaces we trust by habit are the surfaces an attacker values most.
I should say something about the messenger here, because it shapes how the warning should be received. Slow Mist occupies a particular position in the security landscape. The firm's researchers โ Cosine among them โ have a track record of surfacing these small, structural attack patterns before they become mass incidents. When an organization like that issues a warning about bookmarks, the instinct to dismiss it as obscure is exactly the instinct the attacker is counting on. Obscurity is not the same as irrelevance. A vector that most people have never heard of is a vector most people have no defense against. Art is not just seen; it is verified and held โ and the same standard we apply to provenance in digital art should apply to the integrity of our access. Ownership means nothing if the proof of ownership can be replayed by anyone who tricks you into a click.
And this is where I want to turn, because the comfortable reading of this story โ the one that will dominate the replies and the group chats โ is the wrong one.
The comfortable reading goes like this: a careless user was tricked into dragging malware into their browser, then foolishly clicked it, and lost their money. The lesson is "don't click strange things." The victim is the variable. Be smarter than the victim.
I want to dismantle that reading, because it is both cruel and strategically useless.
The FOMO bookmark attack is not primarily a user-failure story. It is an architecture-failure story, and the industry's habit of blaming the victim is precisely what allows the architecture to remain unfixed. Consider what we are actually asking of users. We ask them to hold a mental model of the browser's security boundaries โ to know, intuitively, that a bookmark can execute code, that a session token is a bearer instrument, that the same-origin policy is a trust boundary they are personally responsible for policing. No reasonable person carries that model. Not the newcomers. Not the day traders. Not, if we are honest, most of the engineers I know who are not working directly on browser security.
We built an industry on the promise of "be your own bank," and then we handed users a bank with no teller, no vault door, and no deposit insurance, and we told them the security model was "be careful." That is not a security model. That is a liability transfer.
The deeper contrarian point concerns sessions themselves. The entire convenience of a web wallet rests on a bearer token โ a piece of data that grants access to anyone who holds it, with no additional proof of identity. This is the same design flaw that makes stolen cookies so devastating across the web. We have spent a decade hardening private keys against theft while leaving the session token โ the actual key to the account while you are logged in โ as soft as a sticky note. The attacker in the FOMO case did not need your seed phrase. They needed the thing that proves you are already logged in. And we made that thing trivially reachable from any script running in the page.
There is a second blind spot, and it concerns the tools we build. Wallet drainers exist because there is a market for stolen assets, yes โ but also because the interfaces we build make draining trivial once access is achieved. A single authenticated API call can empty an account. There is no cooling-off period, no second factor at the moment of transfer, no velocity limit on how fast value can leave. We optimized for frictionless transactions and discovered, too late, that frictionlessness is the same thing as defenselessness when the session is compromised. The word "frictionless" should have been a warning label, not a marketing slogan.
So when the replies fill with "just don't click bookmarks," understand what is being defended. The speaker is defending the comfort of a system that shifts blame downward, onto the user, and away from the design choices that made the attack cheap. A quiet observation in a loud, decentralized room: the loudest security advice is often the least honest. Navigating the storm with an anchor made of code requires us to fix the anchor, not to scold the sailor for being caught in the wind.
This is not to say users bear no responsibility. They do. Vigilance is real, and I will not pretend otherwise. But vigilance has a ceiling, and the attacker only needs to be right once โ or, in this case, two or three times, which is the same asymmetry wearing a different coat. A security model that depends on the user never making a mistake is not a security model. It is a wish.
What would an honest response look like? It would start by acknowledging that the browser's bookmark system is a legacy feature carrying modern risk, and that expecting users to treat their own favorites bar as hostile territory is a demand no consumer product should make. It would continue by hardening sessions: binding tokens to device fingerprints, requiring re-authentication for value-moving actions, treating any transfer above a threshold as a step-up event rather than a routine call. And it would end by treating warnings like Cosine's not as curiosities but as signals โ the early whisper of a pattern that will, if ignored, become a shout.
Let me return to the technical spine one more time, because I want the reader to leave with something actionable rather than merely alarmed. The defense against bookmark phishing is not a single tool. It is a set of habits and a set of configurations, layered.
On the user side, the single most effective habit is this: treat any instruction to drag something into your bookmarks bar โ or to paste code into your console โ as a phishing attempt, without exception, because legitimate applications essentially never require it. No honest verification flow asks you to install a bookmarklet. When a page asks you to, you are not verifying you are human. You are being recruited as the delivery mechanism for your own theft.
On the configuration side, browsers have slowly added guardrails, though they remain inconsistent. Some browsers now warn before running a javascript: bookmarklet on certain pages. Some restrict bookmarklet execution on pages with strict security policies. But these protections are uneven, and relying on them is a bet that the browser you use today will keep pace with the attacker's creativity tomorrow. Do not bet your balance on a browser vendor's roadmap.
On the application side โ the side where FOMO and every other web wallet lives โ the fix is harder and more necessary. Sessions should be short-lived. Tokens should be bound to more than a cookie. Value transfers should require proof that cannot be harvested by a script running in the same origin. None of this is glamorous. All of it is overdue. The sideways market we find ourselves in โ the long, grinding consolidation where nothing seems to happen โ is precisely the moment to do this work. When prices are quiet, the industry has the attention span to fix what the next bull run will expose. Chop is for positioning, and security is a position.
Here is the forward-looking question I want to leave ringing. If a bookmark โ a thirty-year-old convenience, a feature so mundane we forget it exists โ can be repurposed into a weapon that drains a wallet in three clicks, what else in the browser's furniture is waiting to be turned against us? The history of this industry is a history of forgotten surfaces becoming attack surfaces. The seed phrase, the clipboard, the browser extension, and now the favorites bar. Each time, we patch the specific wound and move on, leaving the underlying condition untreated.
The storm is not here yet. But the air has changed, and the whisper from Slow Mist is the kind we should learn to hear before it becomes a shout. The bookmark is not just a bookmark anymore. It is a loaded gun we keep handing to ourselves โ and until the architecture stops arming it, no amount of user vigilance will be enough.