The Across hijack never touched a contract: a domain checklist for DeFi teams

On November 10, 2026, at about 18:45 UTC, an attacker took control of across.to, the website of the Across bridge. According to Across, nobody broke into their servers or their contracts. The attacker used social engineering at their domain registrar, Namecheap, and pointed the domain at a phishing page. Across warned users not to connect wallets and had the domain back the same night. Third-party trackers put losses at a few hundred thousand dollars; that figure is an estimate, not confirmed by Across.

It was not the first attack like this. In late October a registrar-level hijack hit a dozen DeFi front ends at once (Kintsu, Pickle, Origami and others). In April it was CoW Swap. The pattern repeats: audited contracts, unprotected front door.

Two different problems

It helps to split the risk in two, because the defenses are different.

1. Someone takes the whole domain. That is what happened to Across. Once the attacker controls DNS, they serve their own site, with their own headers and their own valid TLS certificate. Nothing on your real server matters any more.

2. Someone changes one script on your real site. A compromised analytics tag, CDN library or npm package runs inside your page, right next to the "Connect wallet" button. BadgerDAO (2021) and the Ledger Connect Kit incident (2023) were this kind.

Checklist for problem 1: the domain

• Registry lock, not only registrar lock. Registrar lock lives in the same account the attacker is trying to talk their way into. Registry lock is set at the registry (for .com/.net and many ccTLDs; .to support varies) and needs an out-of-band, manual confirmation to change nameservers. Ask your registrar if they offer it; enterprise registrars usually do.
• Hardware-key 2FA on the registrar account, and a registrar that does not let support reset it over chat.
• Alerts on NS and A record changes. A simple job that resolves your domain every few minutes from outside and pages you when nameservers or IPs change turns hours into minutes.
• CAA records naming the only CA allowed to issue certificates for you. They do not stop a full DNS takeover (the attacker can change CAA too), but they block mis-issuance while DNS is still yours.
• A tested plan: who calls the registrar, which channel announces "do not use the site", and where users can verify the warning.

Checklist for problem 2: the page

• Content-Security-Policy listing where scripts may load from and where the page may send data.
• Subresource Integrity on third-party scripts with fixed content.
• frame-ancestors / X-Frame-Options, so the dApp cannot be framed for clickjacking.
• HSTS, so browsers never fall back to plain HTTP.

How common is problem 2?

Earlier this month we passively checked the home pages of 1,000 random DeFi protocols from DefiLlama (only what any browser receives, no attacks, aggregated numbers only). Of the sites that answered:

Full method: https://dev.to/alex_simakov_d5176f3977ad/we-checked-1000-defi-websites-76-have-no-csp-and-64-can-be-framed-by-another-site-5m5

To be clear: none of these headers would have saved Across. They matter for the other half of the problem, which is more common.

Check your own site

If you want to see where your front end stands on problem 2, our free passive check takes about 15 seconds and needs no sign-up: https://mcp.pasportoo.com/check?utm_source=devto

Disclosure: I build Pasportoo, the tool behind that check and the study above.

Sources

• Across Protocol on X: https://x.com/AcrossProtocol/status/2120278803318489362 and https://x.com/AcrossProtocol/status/2120324818385912082
• Coin Bureau alert: https://x.com/coinbureau/status/2120312029772964212
• October registrar-level hijacks: https://forklog.com/en/news/hackers-hijack-domains-of-15-defi-projects
• Blockaid on front-end hijacking: https://blockaid.io/blog/frontend-hijacking-and-the-web2-attack-surface-threatening-web3-protocols