DEV Community

ohmygod
ohmygod

Posted on

Web2 Is Still Web3's Kill Switch: Dissecting the Bonk.fun Domain Hijack That Drained Solana Wallets

#solana #security #defi #web3

TL;DR

On March 11, 2026, attackers hijacked the domain of Bonk.fun — a Solana meme coin launchpad — and replaced its frontend with a wallet drainer disguised as a Terms of Service update. At least 35 wallets were compromised. The smart contracts were fine. The blockchain was fine. A DNS record was all it took.

This incident, coming weeks after the $40M Step Finance treasury compromise, is a brutal reminder: the most dangerous attack surface in DeFi isn't your Solidity or Rust code — it's everything around it.

The Attack Timeline

March 11, 2026 — Initial Compromise

Attackers gained access to a team-associated account connected to Bonk.fun's domain infrastructure. The exact vector hasn't been publicly confirmed, but the pattern matches credential compromise or social engineering against a domain registrar or DNS provider.

March 11-12 — Frontend Weaponization

With domain control, the attackers:

  1. Replaced the legitimate frontend with a malicious clone
  2. Injected a fake "Terms of Service update" modal
  3. When users connected wallets and signed the prompt, they unknowingly approved a transaction granting the attacker permission to drain their tokens

March 12 — Detection and Response

The Bonk.fun team detected the compromise and issued urgent warnings on X, telling users to avoid the site. They clarified:

  • BONK token itself was unaffected
  • Solana smart contracts were untouched
  • Raydium infrastructure was not involved
  • Only users who signed the fake ToS after the hijack were at risk

Damage Assessment: ~35 wallets compromised, ~$23,000 drained across attacker addresses. One user reported losing ~$273,000 (unconfirmed independently).

Anatomy of a Frontend Attack

Let's break down why this attack class is so effective and so hard to defend against.

The Trust Model Is Broken

When a user visits bonk.fun, their browser trusts the DNS resolution, TLS certificate, and served JavaScript implicitly. There is no on-chain verification that the frontend code matches any expected hash. The user's wallet (Phantom, Solflare, etc.) sees a legitimate domain with a valid certificate and presents the transaction for signing.

User → DNS → CDN/Server → Frontend JS → Wallet Prompt → Signed Tx → Chain

     ↑ Attacker controls this    ↑ Attacker controls this
Enter fullscreen mode Exit fullscreen mode

The attacker doesn't need to break cryptography. They need to break a GoDaddy password.

Why Wallet Prompts Aren't Enough

Modern Solana wallets show transaction details before signing, but:

  • Approval transactions look benign — a setAuthority or token approval doesn't scream "I'm draining you"
  • Users are trained to click through — how many ToS updates have you skipped reading?
  • Context collapse — the wallet can't distinguish "legitimate dApp requesting access" from "attacker-controlled frontend requesting access"

The Web2/Web3 Gap

Smart contract auditors audit smart contracts. Frontend code is typically:

  • Not audited with the same rigor
  • Deployed from CI/CD pipelines with different access controls
  • Served from centralized infrastructure (DNS, CDN, hosting providers)
  • Updated without on-chain governance or multisig approval

This creates an asymmetric security model: millions spent auditing 500 lines of Rust, zero spent securing the DNS registrar account.

Pattern Recognition: This Keeps Happening

Bonk.fun isn't novel. This is a well-established attack pattern:

Incident Date Vector Impact
Curve Finance Aug 2022 DNS hijack Frontend drainer
Convex Finance Jun 2022 DNS hijack Approval phishing
KyberSwap Sep 2022 Frontend injection via GTM Approval phishing
Balancer Sep 2023 DNS hijack Frontend drainer
Galxe Oct 2023 DNS hijack via social engineering Wallet drainer
Bonk.fun Mar 2026 Domain hijack Wallet drainer

Four years later, the same attack keeps working. That's not an attacker innovation problem — it's a defender complacency problem.

Defense Layers: What DeFi Teams Should Actually Do

1. Domain Security (Non-Negotiable) 

✅ Registrar lock enabled
✅ DNSSEC configured and validated
✅ Registrar account uses hardware 2FA (not SMS, not TOTP app)
✅ Domain transfer lock with out-of-band confirmation
✅ Separate registrar account from team email domains
✅ Registry lock (if TLD supports it — .com, .net, .org do)
Enter fullscreen mode Exit fullscreen mode

Registry lock is the nuclear option: changes require manual verification through the registrar, often via phone callback. It's inconvenient. It also would have prevented this attack.

2. Frontend Integrity Verification

Subresource Integrity (SRI) for all loaded scripts:

<script src="app.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>
Enter fullscreen mode Exit fullscreen mode

Content Security Policy (CSP) headers to prevent injection:

Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-{hash}'; connect-src 'self' https://api.mainnet-beta.solana.com;
Enter fullscreen mode Exit fullscreen mode

On-chain frontend hashing — emerging pattern where the expected frontend bundle hash is stored on-chain or in a multisig-controlled registry:

// Pseudo-code: frontend registry
pub fn verify_frontend(ctx: Context<Verify>, bundle_hash: [u8; 32]) -> Result<()> {
    require!(
        ctx.accounts.registry.current_hash == bundle_hash,
        ErrorCode::FrontendTampered
    );
    Ok(())
}
Enter fullscreen mode Exit fullscreen mode

Browser extensions like Wallet Guard and custom verification scripts can check this before allowing transactions.

3. Deployment Pipeline Hardening 

✅ CI/CD deploys require 2-of-N approval
✅ Deploy keys stored in HSM or hardware-backed secrets manager
✅ Git signing required for all deploy-triggering commits
✅ Deployment notifications to security channel
✅ Canary checks post-deploy (automated frontend hash verification)
Enter fullscreen mode Exit fullscreen mode

4. User-Side Defenses

For users who can't trust that every dApp has done the above:

  • Transaction simulation — use Blowfish, Pocket Universe, or wallet-native simulation to preview what a transaction actually does before signing
  • Revoke old approvals — tools like revoke.cash for EVM, sol-incinerator for Solana
  • Bookmark, don't search — navigate to dApps via bookmarks, never search results or links from social media
  • Hardware wallet for large holdings — the signing step on a Ledger shows the raw transaction, making drainer prompts more visible

The Bigger Picture: Operational Security in DeFi

The Bonk.fun hijack happened two months after Step Finance lost $40M from compromised executive devices. These aren't smart contract bugs. They're operational security failures.

The DeFi industry has an opsec maturity problem:

  • Protocol treasuries controlled by hot wallets on internet-connected devices
  • Team accounts on centralized services (registrars, hosting, CI/CD) using weak authentication
  • No separation between development infrastructure and production signing authority
  • Incident response is "post on Twitter and hope people see it"

Compare this to traditional finance, where operational controls are the primary security layer. DeFi has inverted the model: cryptographic security is excellent, but the humans and infrastructure around it are barely protected.

Recommendations

For Protocol Teams

  1. Threat model your Web2 stack with the same rigor as your smart contracts
  2. Registry-lock your domains — the 24-hour inconvenience for changes is worth it
  3. Implement frontend integrity checks — on-chain hash registry + CSP + SRI
  4. Use hardware-backed auth everywhere — YubiKeys for registrar, hosting, CI/CD, email
  5. Run tabletop exercises — "What if our domain is hijacked at 3 AM?" Have a plan, not just hope

For Users

  1. Simulate before signing — always
  2. Bookmark your dApps — never trust links
  3. Revoke unused approvals — monthly hygiene
  4. Use hardware wallets for anything you can't afford to lose
  5. If a dApp suddenly asks you to sign a new ToS — close the tab and check their Twitter

For Wallet Developers

  1. Flag suspicious approval patterns — new approval requests from previously-trusted domains should get extra scrutiny
  2. Domain change detection — if the IP/certificate of a known dApp changes, warn the user
  3. Transaction simulation by default — don't make safety opt-in

Conclusion

The Bonk.fun domain hijack is a textbook case of the Web2/Web3 security gap. Every dollar spent on smart contract audits is wasted if the frontend serving those contracts can be swapped out by compromising a registrar account.

Until DeFi takes its Web2 infrastructure as seriously as its cryptographic infrastructure, we'll keep writing these post-mortems. The blockchain is trustless. Everything else isn't.

This is part of an ongoing series covering real-world DeFi security incidents, tools, and best practices. Follow for weekly deep dives.

Top comments (0)