Blockaid, a crypto security firm, has tied 12 crypto project websites to an active wave of frontend attacks, and two of the named projects, Flap and Kintsu, have confirmed their sites were hit by DNS hijacks. The alert circulated on October 31, 2026, via on-chain reporter Wu Blockchain, and the clustering of a dozen sites at once points to a campaign rather than an isolated slip.
A clone served from the real address
A frontend attack leaves the blockchain and the smart contract untouched. It goes after the website layer, the part a person actually clicks. In a DNS hijack, the attacker takes control of the records that translate a domain name into a server address, then points the domain at infrastructure they control. A visitor who types the correct URL, or clicks a saved link, still lands on a page that looks identical to the real one. The difference sits underneath: wallet connection prompts, deposit addresses, and transaction approvals can all be rewritten to route value to the attacker.
That is the uncomfortable part of this class of attack. The protocol can be audited, the contracts can be clean, and the chain can be running normally, yet a user still loses funds because they signed a malicious transaction on a spoofed page. The perimeter that failed is the domain, not the code.
Flap, Kintsu, and the shape of a coordinated campaign
Flap and Kintsu both acknowledged DNS hijacks, which lines up with Blockaid's broader list of 12 affected sites. When several unrelated projects report the same failure mode in a tight window, the usual suspects are shared dependencies: a common domain registrar, a DNS provider, a hosting or deployment pipeline, or reused credentials exposed in an earlier leak.
Blockaid published the affected set and the two confirmations. A single named root cause was not part of the summary that circulated, so attribution of a shared entry point is still open as of this writing. The practical read does not change either way. If a project you use appears on a frontend-attack list, treat its website as untrusted until the team posts an all-clear and, ideally, a post-mortem explaining what was fixed.
The wallet-signing risk sits with the user
Self-custody puts the final click in your hands. You approve every transaction, which is the point of holding your own keys, and also the exact moment a spoofed frontend tries to exploit. A cloned site cannot move funds on its own. It needs you to connect and sign. That makes the signing screen the last line of defense, and it is why spending from your own wallet carries a different risk profile than letting a custodian hold the keys.
The same trust surface shows up for anyone funding a wallet-linked crypto card or managing on-chain balances through a dApp. The card rails and the chain can be fine while a poisoned domain quietly swaps a deposit address. Reading what you are actually approving, rather than trusting a familiar logo, is the habit that holds up here.
Checks that blunt a frontend attack
A few steps lower the odds of signing on a hijacked page:
- Bookmark official domains and reach dApps through the bookmark, not search results or links dropped in chat.
- Slow down on any prompt asking for a broad token approval or an "approve all" permission you did not expect.
- Use a wallet that previews or simulates a transaction before you confirm, so a swapped address or hidden approval shows up first.
- Confirm the exact destination address on a hardware wallet screen, where a spoofed webpage cannot change what you see.
- Revoke stale token approvals periodically, which limits what a malicious contract can touch even if you slip once.
None of this requires trusting the affected projects to have fixed their DNS. It shifts the check to your side of the transaction, which is the only part a frontend attacker cannot rewrite.
Overview
Blockaid linked 12 crypto project websites to a frontend attack wave, with Flap and Kintsu confirming DNS hijacks, as reported on October 31, 2026. The compromise sits at the website and domain layer, not the chain, so clean contracts give no protection once a user signs on a spoofed page. A named shared root cause was not part of the circulated summary. Until affected teams confirm a fix, the safe posture is to treat their sites as untrusted, reach dApps through saved bookmarks, verify destinations on a hardware wallet, and refuse unexpected broad approvals.
