The Bookmark That Betrays: Inside the FOMO Session-Hijacking Campaign and the Trust We Keep in Our Browsers

The Bookmark That Betrays: Inside the FOMO Session-Hijacking Campaign and the Trust We Keep in Our Browsers

Hook

On the morning of October 8, a security researcher whose handle carries almost mythological weight in our industry posted a warning that, on its surface, sounded like a joke. Slow Mist Cosine — the public-facing voice of one of the most respected blockchain security firms in Asia — reported that a new phishing campaign was targeting the web version of FOMO, and that the weapon of choice was not a malicious smart contract, not a compromised private key, not even a cloned domain. The weapon was a bookmark.

Let that settle. For two decades, we have trained an entire generation of internet users to treat the browser's bookmark bar as the safest real estate on the web. Bookmarks are the things we save because we trust them. They are the shortcuts we build for ourselves, the small conveniences that make the internet feel less like a hostile frontier and more like home. A bookmark is a promise we make to our future selves: this place is worth returning to. And now, according to a report circulating through security channels since the early hours of October 8, that promise is being weaponized.

The mechanics, as described, are almost elegant in their cruelty. A phishing page appears. It asks the visitor to complete what looks like a routine human verification — the kind of CAPTCHA-like ritual we have all performed thousands of times without thinking. But instead of asking the user to identify traffic lights or click on bicycles, this page asks them to drag a small element into their browser's favorites bar and save it as a bookmark. Once that bookmark is saved, the trap is set. When the user later clicks it — two or three times, according to the report — their previously authenticated FOMO account is silently hijacked, and whatever cryptocurrency assets sit inside are swept away before the user even understands what has happened.

This is not a story about a bug. This is a story about trust, and about the places we store it without knowing we are storing it at all.

Context: What Happened on October 8

Let me be precise about what we are dealing with, because precision is the only honest response to fear.

FOMO, in this context, refers to the web version of a cryptocurrency wallet and trading interface — the browser-accessible companion to a mobile application that has, across several cycles, accumulated a meaningful base of users who hold real value inside it. The web version exists for the same reason every web version exists: convenience. Traders want to open a browser tab on a desktop, connect, and move quickly. The web version keeps a session alive so that users do not have to re-authenticate on every refresh. That session persistence is a feature. It is also, in the hands of a patient attacker, a loaded weapon.

Slow Mist is a blockchain security firm whose disclosures have shaped how this industry thinks about operational security. When Slow Mist speaks, the market listens — not because the firm has regulatory authority, but because it has earned something rarer: credibility built on thousands of hours of on-chain forensics and incident response. The attribution matters here. This is not a rumor amplified by anonymous accounts. This is a structured warning from people who investigate theft for a living.

The term at the center of the report is "bookmark phishing," sometimes called bookmarklet phishing. The technique is not new in the abstract — variants have surfaced since the mid-2000s — but its application to a crypto wallet with live, authenticated sessions is what makes the October 8 report so unsettling. The attack does not require the victim to download a file, install an extension, or approve a transaction on-chain. It requires the victim to do something that feels helpful, ceremonial, and safe: save a bookmark.

Here is the essential anatomy. A bookmarklet is a bookmark whose "URL" is not a web address at all but a snippet of JavaScript code. When the user clicks a bookmarklet while viewing a web page, the browser executes that code in the context of the currently open page — with all of that page's permissions, cookies, and session state. This is a legitimate and useful technology. Security professionals use bookmarklets. Developers use bookmarklets. The entire design of the browser, from its earliest days, assumed that the user is the one who writes and installs their own bookmarklets, and that the user therefore consents to whatever the code does. The FOMO campaign inverts that assumption. It gets the user to install someone else's code while believing they are merely proving they are human.

I want to pause on the word "human." Because the choice of "human verification" as the lure is not accidental, and understanding why it works is the difference between a warning and a lesson.

A Brief Taxonomy of Crypto Phishing

To see where the FOMO bookmark attack fits, it helps to map the terrain. Crypto phishing has evolved through several distinct generations, and each generation taught attackers something the next one used.

The first generation was crude domain spoofing. Attackers registered lookalike domains — swapping a lowercase "l" for a capital "I," adding a hyphen, changing a top-level domain — and cloned the login pages of exchanges and wallets. The defense was relatively straightforward: bookmark the real site, check the URL, use a password manager that refuses to autofill on the wrong domain. This generation is still alive, but it is increasingly ineffective against anyone who has absorbed the basic lessons.

The second generation was approval phishing. Rather than stealing a password, attackers persuaded users to sign a transaction that granted an allowance to a malicious contract — often disguised as an airdrop claim or a migration. The victim's keys were never stolen; their permission was. This generation taught the industry that on-chain actions can be weapons even when the wallet itself is secure.

The third generation was address poisoning and clipboard hijacking. Attackers generated addresses that looked similar to ones the victim frequently transacted with, then seeded the victim's transaction history with them, hoping the victim would copy the wrong address from their history. This generation taught us that the human eye is a poor validator of hexadecimal strings.

The fourth generation — the one we are living in now — attacks the browser environment itself. It includes malicious extensions, supply-chain compromises of front-end scripts, and, most recently, bookmarklet phishing. This generation is different in kind, not just degree, because it does not ask the user to trust a wrong thing. It asks the user to trust a right thing — their own bookmark bar — and then subverts that trust from within.

The FOMO campaign belongs to this fourth generation. And like every generation before it, it will teach attackers something that the next wave will use.

The Technical Anatomy of a Bookmarklet, and Why the Browser Allows This

I want to spend real time on the mechanism, because vague warnings help no one. If you understand how a bookmarklet works, you will understand why this attack is possible at all — and why it is so hard to stop with the tools we currently have.

A bookmarklet is a bookmark that begins with the javascript: scheme instead of https:. When you click it, the browser takes the code that follows javascript: and evaluates it in the context of the page currently displayed in the active tab. This is not a bug; it is a feature that predates the modern web. It exists because early browser designers wanted users to be able to extend their browsing experience without installing software. Drag a link to your bookmarks bar, and you have a tiny program that runs whenever you want it.

The security model here is subtle and, in retrospect, fragile. The browser assumes that the person who installs a bookmarklet is the person who wrote it, or at least the person who consciously chose to run it. Consent is the entire security boundary. There is no sandbox around a bookmarklet, because the bookmarklet is supposed to be an expression of the user's own will. It runs with the same authority as the page it is clicked on. If that page is your bank, the bookmarklet can read your bank's DOM. If that page is your authenticated crypto wallet, the bookmarklet can read your session and, depending on the client, act on your behalf.

Modern browsers have added some friction. Content Security Policy headers can restrict what scripts a page may execute, and some browsers warn when a bookmarklet attempts certain operations. But these mitigations are partial at best, and they cannot distinguish a malicious bookmarklet from a benign one, because the code is identical in structure. The only thing that separates a helpful bookmarklet from a hostile one is intent — and intent is not something the browser can read.

This is the crux. The browser cannot protect you from a bookmarklet you were tricked into installing, because the browser was designed on the assumption that you would never be tricked. The attack does not exploit a flaw in the browser. It exploits the browser's foundational trust in the user's judgment. And that trust, once borrowed by an attacker, becomes a bridgehead inside your own machine.

I have spent much of my career inside cryptographic systems, and I have learned to respect the places where security is delegated to human behavior. Those are the places where systems break. Not because humans are weak, but because humans are being asked to perform a security function — consent — without being given the information they need to perform it well. A bookmarklet that looks like a verification button is not a failure of the user. It is a failure of a design that made the user the last line of defense.

How the FOMO Attack Actually Works: A Step-by-Step Reconstruction

Let me reconstruct the likely flow of the campaign, because abstract warnings do not protect anyone. Concrete understanding does.

Step one: the lure. The victim encounters a phishing page. In many reported variants, the entry point is a social channel — a Telegram group, a Discord server, a reply under an official-looking post — or a promoted search result that mimics the FOMO web domain. The page is designed to look like a legitimate FOMO interface, or at least like a gate that stands in front of one. The framing is urgent but not panicked: "Complete verification to continue." "Confirm you are human to access the dashboard." The urgency is calibrated. Too much urgency triggers suspicion; too little fails to overcome inertia.

Step two: the ritual. The page presents an instruction that feels like a CAPTCHA but is not one. The user is told to drag a button or a badge into the bookmarks bar. In some versions, the instruction is dressed up as a security measure: "Save our verification tool so you can re-authenticate quickly." In others, it is dressed as a technical necessity: "Drag this to your favorites to enable access." The common thread is that the action feels small, reversible, and harmless. It is none of those things.

Step three: the implant. When the user drags the element to the bookmarks bar, they are saving a bookmarklet — a JavaScript payload disguised as a web address. The browser stores it exactly as it would store any other bookmark. No file is downloaded. No extension is installed. No antivirus flag fires, because there is nothing conventional for an antivirus to flag. The malicious code now lives inside the user's own browser, in the one place the user trusts most.

Step four: the trigger. This is where the reported detail about "two or three clicks" becomes important, and where I have to reason carefully, because the report describes an effect rather than a full technical teardown. A bookmarklet only executes when it is clicked on a page where its code makes sense. The attacker's code is designed to run in the context of the authenticated FOMO web session. So the victim must be on the FOMO site — logged in — when they click. The instruction on the phishing page typically nudges the user toward that state: "Now return to FOMO and click the saved bookmark to finish verification." The first click may run a check or a setup routine. The second may capture the session token. The third may confirm that the hijack succeeded or trigger the transfer. The exact number is less important than the principle: the user, not the attacker, performs every step of the compromise, and does so while believing they are securing their account.

Step five: the sweep. Once the bookmarklet has captured the session — a cookie, a localStorage token, a bearer credential, whatever the FOMO web client uses to recognize an authenticated user — the attacker no longer needs the victim. The session is the identity. With a valid session, the attacker can act as the victim: view balances, initiate withdrawals, authorize transfers to attacker-controlled addresses. Because the session was already authenticated, there may be no password prompt, no two-factor challenge, no on-chain approval that the victim would recognize as suspicious. The assets leave. The victim, staring at a still-open tab, may not realize anything is wrong until they try to use the account and find it empty.

I want to be careful and honest here: the precise internal mechanics of any given variant can differ, and Slow Mist's public reporting gives us the shape of the attack rather than a line-by-line teardown. But the shape is enough to be alarmed about, because the shape is a template. What happened to FOMO users on October 8 is not a one-off. It is a reusable pattern.

Why "Human Verification" Is the Perfect Lure

The genius — and I use that word with distaste — of this campaign is the disguise. "Verify you are human" is one of the most powerful compliance triggers on the modern internet. We have been trained, for well over a decade, to treat human verification as a neutral, boring, slightly annoying step that stands between us and whatever we actually want. We do not read the fine print of a CAPTCHA. We do not interrogate why a site wants us to prove our humanity. We just want to get through the gate.

Attackers understand that the strongest social engineering does not ask the victim to do something new. It asks the victim to do something old, in a slightly wrong place. The drag-to-bookmark instruction is unfamiliar, but it is wrapped inside a familiar frame — verification — and that frame suppresses scrutiny. The user thinks: this is weird, but it is verification, so it must be fine.

There is a deeper layer here, and it connects to something I have watched play out across every cycle of this industry. Crypto users are uniquely conditioned to perform security theater. We have been told, endlessly and correctly, to check contracts, to verify domains, to be paranoid. Over time, paranoia becomes ritual. And ritual becomes reflexive. When a user is asked to perform a security action — save a verification tool, confirm humanity, re-authenticate — the request lands in a part of the brain that has been trained to comply. The attacker is not exploiting ignorance. The attacker is exploiting diligence.

In 2020, during the DeFi Summer, I founded the Mumbai Chain Guardians — a volunteer network of two hundred community moderators who monitored Aave and Compound for smart contract vulnerabilities. What I learned in that period reshaped how I think about security forever. The threat we were most worried about was technical: a bug in a contract, an oracle manipulation, a flash loan attack. But the threat that actually caused the most damage was emotional. When the April crash hit, the danger was not the code. The danger was panic. New retail investors, terrified and uninformed, were one bad decision away from a self-inflicted loss. We translated fifty technical upgrade proposals into simple, empathetic guides in Hindi and English and distributed them through WhatsApp groups. That effort, I believe, helped prevent a panic sell-off. Not because we were smarter than the attackers, but because we understood that trust, at scale, is built through education, not through fear.

The FOMO bookmark attack is the inverse of that insight. It shows what happens when someone uses the same understanding of human psychology — but to destroy trust instead of building it. Trust is not a protocol, it is a practice. And a practice can be hijacked just as surely as a session token.

Where Your Identity Actually Lives: The Session

Most crypto users believe, at some level, that their security lives in their private keys. This is true on-chain, and it is almost entirely irrelevant to the attack in question. The FOMO bookmark campaign does not touch your keys directly, and it does not need to. It attacks the layer above the keys: the session.

Here is the concept I want every reader to internalize. When you log into a web application, the server does not remember you as a person. It remembers you as a token — a string of characters that it issued to your browser after you proved you were you. As long as your browser presents that token, the server treats whoever holds it as you. The token is the identity. The password was merely the ceremony that produced the token.

This is why bookmarklet attacks are so devastating against wallets and exchanges. The entire architecture of "stay logged in" is an architecture of delegated trust. The server trusts the browser, and the browser trusts whatever code runs inside it. A bookmarklet runs with the full authority of the page it is clicked on. If that page is your authenticated FOMO dashboard, then the bookmarklet is, for those few seconds, you. It can read your session token. It can read your balance. It can, if the client exposes such functionality, initiate actions on your behalf.

This is the part of the story that I find most sobering, and it is the part that connects to my work on the "Decentralized AI Bill of Rights" in 2026. When we drafted that framework — a consensus document eventually signed by five hundred Web3 organizations — one of the hardest questions was accountability. If an AI model on-chain makes a decision that harms a user, who is responsible? The model? The developer? The user who clicked "accept"? We spent months in workshops across ten countries trying to answer that, and we kept running into the same wall: the systems we build delegate enormous authority to components that users cannot see and do not understand. The session token is exactly such a component. It is invisible, it is powerful, and the user has no mental model of it. An attacker who understands it can impersonate you perfectly, and you will never see a warning.

Why Two or Three Clicks? The Timing of Betrayal

The reported detail that the account is hijacked after "two or three clicks" deserves its own examination, because it tells us something about how the attacker thinks.

If the goal were merely to steal a session token, a single click would suffice. The bookmarklet would run once on the authenticated page, exfiltrate the token, and the attacker would be done. The fact that the attack reportedly requires repeated clicks suggests a design that is either more careful or more conditional — and both possibilities are instructive.

Possibility one: the bookmarklet needs the user to be on the correct page. A user who saves the bookmark on the phishing page and immediately clicks it would be running the code in the wrong context. The attacker's instructions therefore have to shepherd the user back to FOMO, logged in, before the payload can fire. The repeated clicks may simply be the attacker's way of ensuring the user is in the right place.

Possibility two: the payload is staged. The first click might install a listener or a persistent hook; the second might wait for the session to be validated; the third might execute the theft. Staging reduces the chance of a failed attempt that would alert the user.

Possibility three — and this is the one that unsettles me most — the repeated clicks are a deliberate psychological device. Asking a user to click something "two or three times to complete verification" mirrors the rhythm of legitimate multi-step authentication. It makes the process feel official. It also spreads the moment of compromise across several actions, so that no single click feels like the one that mattered. By the time the theft occurs, the user has already normalized the behavior. The betrayal is distributed. There is no single instant of violation to point to.

I do not know which of these is true for any specific variant, and honesty requires me to say so. But all three possibilities point in the same direction: this attack was designed by someone who thinks about human behavior as carefully as they think about code.

Why FOMO, Why Now: The Demographics of a Target

A reasonable reader might ask: why FOMO? Why a wallet's web interface rather than a bank, an exchange, or a social platform?

The answer lies in the intersection of three factors.

First, crypto users hold assets that are liquid, borderless, and irreversible. A stolen bank balance can sometimes be clawed back. A stolen crypto balance, once moved to an attacker's address and routed through mixers or bridges, is effectively gone. The attacker's return on effort is higher in crypto than almost anywhere else.

Second, web wallets carry a heavier-than-necessary session. To be usable, a web wallet must keep users logged in and must expose balance and transfer functionality to the client. That combination — persistent identity plus powerful actions — is exactly what a session-stealing payload wants.

Third, and most importantly, the FOMO user base is not a homogeneous crowd of experts. It includes people who came for the culture, for the community, for the promise of ownership. In 2021, I partnered with the Tata Trusts to launch "Heritage on Chain," an NFT initiative that preserved a thousand endangered Indian textile patterns as ERC-721 tokens. We raised a hundred and fifty thousand dollars in ETH, and seventy percent of the proceeds went directly to artisan communities. That project taught me something the price charts never could: the people entering this space are not all here to trade. Many are here to belong. They are motivated by story, by identity, by the feeling of being part of something. Those users are precisely the ones most vulnerable to a lure framed as verification, because verification is the price of admission to a community they want to join.

The attacker chose a target with a diverse, emotionally invested, and partially non-technical user base. That is not an accident. It is a market segmentation strategy.

The Economics of a Bookmark: Why This Attack Is Worth Someone's Time

I want to spend a moment on the economics, because understanding incentives is how we predict the next attack.

Consider the cost side. Building a convincing phishing page is cheap. Writing a bookmarklet that reads a session token is trivial for anyone with basic JavaScript skills — the payload may be fewer than ten lines. Distributing the lure through social channels costs nothing but patience. There is no infrastructure to maintain, no exploit to sell, no zero-day to burn. The entire attack can be assembled by a single competent person in an afternoon.

Now consider the return side. A single compromised web wallet can hold anything from a few hundred dollars to seven figures. Because crypto transfers are irreversible and borderless, the attacker does not need to launder through a bank; they can route funds through a chain of wallets and bridges, or convert to a privacy-focused asset, and the trace becomes exponentially harder. The expected value of the attack is high, the cost is low, and the risk of consequence is negligible in most jurisdictions.

This asymmetry is the engine of the entire phishing economy. When the cost of an attack is measured in hours and the payoff is measured in life-changing sums, attacks proliferate regardless of how many warnings we publish. The only durable defense is to raise the cost of the attack — which means making the session harder to steal, the interface harder to imitate, and the user harder to social-engineer. All three are architectural problems, not awareness problems.

The Defense Gap: Auditing Code, Ignoring Cognition

Here is where I want to push against the way our industry typically responds to incidents like this.

When a smart contract is exploited, we know what to do. We commission audits. We publish post-mortems. We add the attacker's address to blocklists. We debate the fine points of reentrancy and oracle design. This is the machinery of "Auditing the soul behind the smart contract" — except that phrase is usually aspirational, and most audits stop at the code. They examine the contract's logic, its permissions, its arithmetic. They do not examine the contract's relationship with the human who will use it.

The FOMO bookmark attack does not live in the contract layer. It lives in the space between the code and the cognition. And that space is almost entirely unaudited. There is no established discipline of "human-factors audit" for crypto products, no standard checklist for "does this interface train users to perform dangerous rituals?" We have SOC 2 for data centers. We have formal verification for contracts. We have nothing comparable for the mental models our interfaces install in our users.

This gap is the real finding of the October 8 report, even if Slow Mist did not phrase it that way. The industry's defensive posture assumes that attackers go after code, so we fortify code. But the most efficient attacks of the next decade will go after behavior, because behavior is where the least resistance lies. You do not need to break a smart contract if you can convince its user to hand you the session.

I have seen this pattern before, in a different domain. During the 2022 Terra/Luna collapse, when the market-wide panic hit, I organized weekly "Resilience Calls" for three hundred female crypto founders and community managers who were facing burnout and financial loss. I did not offer trading advice. I facilitated conversations about mental health and community sustainability. What I observed during those months was that the industry's greatest vulnerability was not technical. It was emotional. People made catastrophic decisions not because they lacked information but because they were exhausted, frightened, and alone. The same is true of phishing. The victim of a bookmark attack is not stupid. They are trusting, and they are tired, and they have been trained by years of legitimate verification prompts to comply.

Who Is Liable When a Session Is Stolen?

There is a question buried in the FOMO incident that the industry prefers to avoid, and I want to surface it.

When a user's session is stolen and their assets are drained, who bears the loss? The user, who was tricked? The wallet provider, whose session architecture made the theft possible? The platform that hosted the phishing content? The browser vendor, whose security model allows bookmarklets to run with page authority? The attacker, who is anonymous and unreachable?

In most cases, the answer today is: the user. The user bears the loss, because there is no legal framework that assigns responsibility for a session hijack, and because the crypto industry's default posture is self-custody, which in practice means self-liability. This is philosophically coherent and practically cruel. It means that the party with the least information and the least power absorbs the entire cost of a design decision made by parties with far more of both.

I am not arguing for a bailout culture. I am arguing for something more modest: transparency about risk. If a wallet keeps a high-authority session alive in a browser tab, users deserve to know that this is a trade-off, and they deserve interface cues that make the risk legible. A user who understands that "logged in" means "a stolen token equals a stolen account" will behave differently from a user who believes their password is their shield. The FOMO incident is, at bottom, an education failure — but not a failure of users to educate themselves. It is a failure of builders to educate users about the architectures they depend on.

Building bridges where DeFi once built walls means accepting that responsibility does not end at the edge of the code. It extends to the person on the other side of the screen.

Contrarian: The Real Vulnerability Is the Mental Model

Now let me offer the counter-intuitive reading that I think this incident demands.

The conventional lesson from a phishing story is "be more careful." Do not click suspicious links. Verify domains. Enable two-factor authentication. These are true, and they are also almost useless, because they assume the victim can distinguish a legitimate ritual from an illegitimate one in the moment. The FOMO bookmark attack is designed precisely to defeat that ability. The whole point of disguising the payload as human verification is that the victim's care is not the variable. The victim can be maximally careful and still be compromised, because the attack does not ask them to be careless. It asks them to be helpful.

So here is the contrarian claim: the failure here is not a failure of user vigilance. It is a failure of interface design philosophy. We have built a web in which "prove you are human" and "grant a stranger access to your session" can be made to look identical. We have built a browser in which the bookmark bar — the most trusted surface in the user's environment — is also a programmable execution environment with no sandbox, no permission prompt, and no warning. And we have built crypto wallets in which the session token is so powerful that stealing it is equivalent to stealing everything, yet so invisible that no user knows it exists.

This is not a user problem. This is an architecture problem wearing a user-problem mask. And the reason we keep blaming users is that blaming users is cheaper than redesigning architectures.

I want to be fair to FOMO here, because I do not know the specifics of their client implementation, and it is easy to criticize from the outside. But I can say this with confidence: any web wallet that keeps a high-authority session alive in a browser tab is, by design, exposed to bookmarklet-class attacks. The mitigation is not "tell users to be careful." The mitigation is architectural — short-lived sessions, per-action re-authentication, binding sessions to something the bookmarklet cannot read, and interface patterns that make "verification" structurally impossible to fake. None of these are exotic. They are just expensive, and they slow down the user experience, and in a bull market nobody wants to slow down.

Liquidity flows, but culture remains. And the culture we have built — fast, frictionless, and trusting of the browser — is exactly the culture that bookmark phishing feeds on.

What Builders Owe Users

If I were advising a wallet team tomorrow, here is what I would tell them, and it flows directly from the principle that from code audits to community heartbeats, security must be measured in human outcomes.

First, treat the session as a security boundary, not a convenience feature. A session that can move funds should be short-lived and scoped. If a user is going to authorize a transfer, they should be re-prompted in a way that a bookmarklet cannot spoof. The goal is to make the session token insufficient, by itself, to drain an account.

Second, audit the onboarding and verification flows as aggressively as you audit the contracts. Every instruction you give a user is a script they will follow. If your flow ever asks a user to do something unusual — drag, save, copy, paste, install — stop and ask whether an attacker could imitate that request. If the answer is yes, redesign the flow so that the legitimate request is structurally distinguishable from the fake.

Third, invest in user education that is empathetic rather than accusatory. I learned this in the Mumbai Chain Guardians work: people do not absorb security lessons delivered as scolding. They absorb them delivered as care. A wallet that tells its users "here is why we will never ask you to drag anything into your bookmarks" is doing more for security than a hundred blog posts about phishing.

Fourth, share incident data quickly and without ego. Slow Mist's willingness to publish the FOMO bookmark warning is the reason I can write this article at all. The industry's ability to defend itself depends on this kind of fast, specific, unglamorous disclosure. The firms that hide their incidents are not protecting their users; they are protecting their reputations, and the two are not the same.

A Field Guide for the Next Incident

Warnings tend to be abstract, so let me make this concrete, without turning it into a checklist that reads like a substitute for thought.

If a page ever asks you to drag something into your bookmarks bar, treat that request as a red flag, regardless of how official the page looks. No legitimate human verification has ever required you to modify your browser's bookmarks. Real verification happens inside the page, not inside your browser chrome.

If you have already saved something like this, open your bookmarks manager and inspect the entry. A bookmark that begins with javascript: instead of https:// is code, not a destination. Delete it. Do not click it to "test" it. Clicking it is the attack.

If you suspect a session has been hijacked, the first move is not to investigate — it is to revoke. Log out of every device, change credentials, and move assets to a freshly generated wallet whose keys were never typed into a browser session. Speed matters more than understanding in the first minutes.

And if you build wallets, add a line to your security documentation that says, plainly: "We will never ask you to save a bookmark, drag a button, or paste code into your browser." Then hold yourself to it. The strongest security promises are the ones that are easy to keep and easy to verify.

Takeaway

The bookmark that stole FOMO users' assets on October 8 is a small object, but it is a large signal. It tells us that the next generation of attacks will not look like the last. They will not announce themselves with a fake domain and a broken padlock. They will arrive disguised as the very rituals we have taught users to trust — verification, authentication, safety. They will hide in the browser, in the session, in the mental model. And they will succeed not because users are careless, but because our architectures have made care insufficient.

The question I want to leave you with is not "how do we teach users to spot a bookmarklet?" It is this: what would our wallets, our browsers, and our interfaces look like if we designed them on the assumption that trust is not a protocol, it is a practice — and that a practice must be protected by design, not by warning? Until we answer that, every bookmark is a potential betrayal, and every verification prompt is a door we have left unlocked.