The malicious JavaScript never ran on the phishing page. That is the entire case, and it is the part nearly everyone reading the Slow Mist advisory will skip past.
On October 8, Slow Mist founder Yuxian published a warning about a bookmark phishing campaign aimed at a Web platform called FOMO. The bait is old: a fake "prove you are human" verification screen. The payload is where it gets interesting. Victims are instructed to drag a piece of the page into their browser's bookmarks bar. Then they log into FOMO like any other day. Then they click that saved bookmark โ two or three times, per the report. And that is when the trap fires. Not from an attacker's server. Not inside a sandbox. Inside the FOMO domain itself, running with FOMO's own origin, reading FOMO's own cookies, and moving the victim's assets out the door.
No smart contract was breached. No private key was cracked. No signature was forged. The blockchain recorded nothing unusual until the funds were already in a wallet that was never the victim's.
That is the anomaly worth a full teardown. Follow the gas, not the narrative.
Context
Let me establish what we actually know before I start drawing conclusions, because the biggest risk in a story like this is filling gaps with assumptions.
The confirmed entities are three. Slow Mist is the reporting party โ a Chinese-language security firm that has, over multiple cycles, published alerts that later proved accurate. Yuxian is its founder. FOMO is the named target, described only as a "Web platform." The attacker is unnamed, and the advisory gives no attribution.
Here is the first hard boundary: the specific identity of "FOMO" cannot be confirmed. There are several platforms using that name โ a game, a social layer, a trading interface, a wallet-adjacent app. Until you know which one, any statement about its token, its team, or its valuation is speculation dressed as analysis. I am flagging this early because the temptation to treat "FOMO" as a single known quantity is exactly how bad security reporting starts.
What is not in doubt is the mechanism, and the mechanism is what matters. Let me define the terms, because the attack only makes sense once you understand the tool it abuses.
A bookmarklet is a bookmark whose destination is not a web address but a line of JavaScript. It begins with the javascript: protocol. When you click it, the browser does not navigate anywhere โ it executes that code in the context of whatever page you are currently viewing. This is a legitimate feature. Password managers use it. Reference tools use it. It has existed for over a decade.
The Same-Origin Policy (SOP) is the browser's core defense: a script loaded from one domain cannot read the data of another. Your bank's site cannot read your email's cookies. But SOP has an inside face. Code running with the same origin as the page it is on is not an intruder โ it is a native. It can read that origin's cookies, its localStorage, its session tokens, and it can act as the logged-in user.
Combine the two and you have the whole attack. The phishing page never needs to steal anything directly. It only needs to get a javascript: payload saved as a bookmark, and get the user to click it while they are authenticated on the real FOMO domain. At that instant, the malicious code is not a foreign script. It is FOMO talking to itself.
The chain runs in four steps: a phishing page presents a fake human-verification prompt; the user is instructed to drag a malicious JavaScript snippet into the bookmarks bar and save it; later, while logged into FOMO, the user clicks the bookmark two to three times; the payload executes in the FOMO origin, reads the session, and transfers assets.
The advisory notes that the assets are "immediately stolen." That word โ immediately โ is a signal, and I will come back to it.
Core
Now the technical work. I have spent years on the defensive side of this. I audited over fifty ICO contracts in 2017 looking for reentrancy flaws, and the discipline that taught me applies here in a slightly different form: when an attack looks exotic, check whether it is actually just an old primitive wearing new clothes.
The first finding: this is not a smart contract attack. It is a client-side, human-in-the-loop attack. The distinction is not academic. Smart contract risk lives on-chain and is auditable โ you can read the bytecode, you can simulate the transactions, you can verify the source hash. This attack lives in the space between a browser, a user's hand, and a front-end's trust assumptions. There is no bytecode to read. There is no block explorer for the moment a user drags the wrong thing into their toolbar.
The second finding: the "two to three clicks" requirement is the most diagnostic detail in the entire report. Why would a payload need more than one click? Three plausible explanations, and they are not mutually exclusive. First, a multi-stage loader โ the first click fetches or decrypts the next stage, which then executes on a later click. Second, a rate-limit or confirmation bypass โ some platforms prompt again before a sensitive action, and repeated clicks may be how the payload steps through that sequence. Third, and most likely in my read, the payload is doing two distinct jobs: first read the credentials, then initiate the transfer. Two clicks, two actions. That is a working hypothesis, not a confirmed fact โ but the structure of the requirement points at a script that does more than one thing.
The third finding: this attack is engineered to defeat the defenses people actually rely on. Think about what a normal user or platform has in place. A domain blacklist. URL scanning. Browser warnings on known phishing hosts. On-chain monitoring for suspicious outflows. The bookmarklet attack slips past every one of them, and it does so for a structural reason: the malicious code never sits on a flagged domain, and it never fires on the phishing page. The phishing page only distributes the payload. The payload lies dormant โ a saved bookmark, invisible, inert โ until the user is authenticated on the legitimate site. By the time anything executes, the user is on a trusted domain, with a valid session, performing an action that the platform has no reason to treat as hostile.
That is the crux. The attack does not break the browser's trust model. It exploits it. It gets the user to voluntarily install a same-origin agent and then trigger it from inside the castle walls. Domain reputation systems cannot flag what is not running on a flagged domain. On-chain monitors cannot flag a session read, because a session read is not a transaction.
The fourth finding, and the one with the biggest downstream implications: the custody model determines the blast radius, and the report does not tell us which model FOMO uses. This is the single most important missing variable.
If FOMO is custodial โ if a valid session is sufficient to move funds โ then a hijacked session is a hijacked wallet. The attacker needs no private key because the platform holds it, and the user's credentials are the only lock. In that architecture, session theft equals instant, total loss. The phrase "immediately stolen" is consistent with this model.
If FOMO is self-custodial โ if every transfer requires a fresh signature from a key the user holds โ then the attack surface narrows sharply. An attacker who lifts a session can read balances and prepare transactions, but cannot sign them. The user still has to approve, and that is a checkpoint the attacker has to defeat.
The advisory does not say which. That silence is the difference between "users lost their logins" and "users lost their money," and anyone modeling the risk needs to know which one they are dealing with.
The fifth finding: the "fake human verification" wrapper places this squarely in a known and growing family. Security researchers have a name for this pattern โ the fake CAPTCHA, sometimes called ClickFix. The defining trait is that the attacker hijacks an action users have been trained to trust. "Prove you are human" is one of the most repeated, most trusted micro-interactions on the web. Users have clicked thousands of checkboxes and solved hundreds of image grids. The reflex is to comply. The attacker borrows that reflex and redirects it โ not to a checkbox, but to a drag-and-drop that installs a live payload.
That is not a technical exploit. It is a behavioral one, and it is the most dangerous component here, because it weaponizes compliance. The victim is not tricked into doing something they know is risky. They are tricked into doing something that feels like a security check.
I want to add a forensic note on the "immediately stolen" language. For a script to move assets the instant it executes, it has to know the platform's transfer flow โ the endpoint, the payload shape, the confirmation steps. That is not generic phishing kit behavior. It suggests the attacker either reverse-engineered FOMO's front-end or had some internal knowledge of it. Either way, it points to a prepared, targeted operation rather than an opportunistic spray. Follow the gas, not the narrative โ and the gas here says the attacker did their homework.
One more structural point, drawn from how I map these things on-chain. In my 2021 work mapping CryptoPunk whales, I learned that "organic" behavior often isn't. I built clusters of wallets, tracked their funding sources, and found that what looked like a broad community was frequently a small coordinated set. The same lens applies to the distribution side of this attack. To funnel victims to a phishing page and get them to complete a drag-and-drop, the attacker needs traffic โ social ads, community links, SEO poisoning, direct messages. That requires budget and reach. An operation with reach and a reverse-engineered payload is an operation with resources. This is not a lone script kiddie. That conclusion changes how the response should be scoped.
Let me also address what the report conspicuously does not say, because the gaps are evidence too. It does not name a victim count. It does not describe FOMO's response. It does not specify the custody model. It does not describe the on-chain destination of the stolen assets. And it does not say whether the javascript: bookmark was blocked or warned against by any browser. Four of those five gaps are things a platform or an investigator could fill within days. Their absence in a public advisory is a signal about how early in the response cycle we are.
Contrarian
Here is where I push against the comfortable reading, because the comfortable reading is the dangerous one.
The prevailing narrative is that if you guard your private key, you are safe. This attack proves that narrative wrong, and the market has not priced that in. The standard crypto-security sermon is simple: never share your seed phrase, never sign a blind transaction, and you are protected. That sermon assumes the threat lives at the key layer. This attack lives one layer up, at the session layer โ and it demonstrates that account sessions can be as lethal as private keys, in the right architecture. A user who never once typed their seed phrase anywhere still lost everything, because the platform held the key and the session was the only gate. Follow the gas, not the narrative: the gas never moved suspiciously until the funds were gone, because the attack did not need a suspicious transaction. It needed a valid one, signed by a session that looked exactly like the victim.
The second contrarian point: this is not a new attack, and calling it one is a category error that weakens the response. Bookmarklet abuse is over a decade old. Self-XSS โ tricking a user into running malicious code themselves โ is older still. What is new is the packaging: the fake CAPTCHA wrapper, the polished drag-and-drop instruction, the social funnel that delivers it. The technique is antique; the delivery is modern. Why does the distinction matter? Because the instinct when something is labeled "novel" is to wait for a novel defense โ a patch, a signature update, a tool. But you cannot patch a technique that has no technical exploit at its core. The core is user behavior, and the only durable defense is education and friction. Framing this as a zero-day tempts people to wait for a fix that will never come.
The third contrarian point: the risk is being misattributed to "smart contract security," and that misattribution is where capital gets misallocated. Spend five minutes in any crypto security conversation and you will hear the same refrain โ audit your contracts, watch your approvals, revoke your allowances. All of that is real, and all of it is aimed at on-chain surface. This attack never touched that surface. It is a front-end and identity-layer failure. The uncomfortable implication is that the security spend in this industry is skewed toward the layer that gets exploited loudly and away from the layer that gets exploited quietly. A drained contract makes headlines and moves prices. A hijacked session makes a footnote and moves nothing โ until it does it at scale.
The fourth contrarian point: the reflex to blame the platform is premature, and the reflex to absolve it is wrong too. We do not know whether FOMO's session timeout was unreasonably long, whether it enforced device binding, whether it used HttpOnly cookies, whether it required a second signature for transfers. Any of those controls would have blunted the attack. Their presence or absence is the real question. But the report does not answer it, and a verdict without evidence is exactly the failure mode a forensic analyst is supposed to avoid. I will not declare the platform negligent. I will say that its response โ and its disclosed security posture โ will tell you more about its competence than any marketing page ever could.
The fifth contrarian point, and the one that should worry the industry most: this technique is cheap to replicate. There is no zero-day to burn, no exploit chain to maintain, no high-skill barrier. A template, a funnel, and a target with an engaged user base are the entire cost. That means the relevant question is not "will this happen again" but "how fast does it spread to the next platform." Security threats that require no scarce input do not stay contained. They propagate.
Takeaway
So what is the forward-looking signal here โ what should you actually watch over the next seven days?
Three things, in order of how much they will tell you.
First, watch the browsers. If this technique spreads, Chrome, Edge, and others face pressure to add warnings or restrictions around javascript: bookmarks. That is the single highest-leverage intervention available, because it attacks the primitive rather than the packaging. A change in browser policy would tell you the industry has recognized the structural problem. Silence would tell you it has not.
Second, watch FOMO's response โ or its silence. A fast, transparent response with forced session invalidation, a public disclosure, and a clear remediation plan is a recoverable event. Silence, or a defensive non-answer, is a trust event that compounds. In my 2022 work dissecting the Terra collapse, I watched the same pattern play out at a larger scale: the magnitude of the loss mattered less than how the operators handled the moment after. The moment after is where trust is either rebuilt or permanently destroyed.
Third, watch the on-chain flow of any stolen funds. If assets hit centralized exchanges, there is a narrow window where KYC/AML systems can flag and freeze them. That window is the last line of defense, and it is thin. In my 2025 work tracking ETF inflows against exchange outflows, I saw how much institutional capital now moves through rails that carry compliance hooks. Those same hooks are the only realistic recovery mechanism for victims here โ not because the chain can be reversed, but because the off-ramp can be watched.
The deeper takeaway is uncomfortable. The industry has spent a decade hardening the layers it can audit and neglecting the layers it cannot. Contracts are inspected; sessions are assumed. Keys are guarded; browsers are trusted. This attack did not find a flaw in the cryptography. It found a flaw in the assumption that a logged-in user is the same person as the account holder. That assumption is everywhere, and it is false.
The signal to watch is not whether FOMO survives this. It is whether anyone treats the session layer as a security boundary worth defending. If the answer is no, then this advisory is not a warning about one platform. It is a preview.
