Across Restores Bridge After Registrar Attack Hands Its Domain to Phishers

Across is back online, but the bridge's six and a half hours offline cost users real money. An attacker took control of its across.to domain after socially engineering its registrar, Namecheap, and the episode is a sharp reminder that a DeFi protocol's security is only as strong as the vendors holding its keys to the front door. Here's the thing: most DeFi teams spend heavily on audited smart contracts and governance safeguards, yet the web front end that users actually click through often sits behind a single login at a domain registrar. That's a soft spot, and this incident exposes it plainly. If you're working in this space, the lesson isn't subtle.

Across announced at 01:16 UTC on Wednesday that the system was "fully restored, and all systems are operational." The attacker had spent Tuesday pointing visitors to a phishing page. The protocol dates the start of the attack to roughly 18:45 UTC on Nov. 10. That window accounts for the bulk of the downtime, and it's where most of the damage happened. Keep in mind that "operational" describes the protocol's own systems. It says much less about whether every user's token approvals have been cleaned up.

How the Takeover Happened

Across blamed the breach on its registrar. In a late Tuesday post, it said a social engineering attack on Namecheap "gave a bad actor control of the Across domain," and that despite its best efforts, Namecheap had been unresponsive. The team insisted the domain was "fully locked down with best-in-class security practices" and that the takeover "should not have been possible." A post-mortem is promised. That's a lot of certainty for a team that just lost control of its own address. Protocol teams often describe their vendor relationships as locked down right up until something breaks, and the lock was real, but it lived on someone else's infrastructure.

Across says it learned of the attack within 15 minutes and moved to take the site offline. SEAL911, a crypto security emergency hotline, flagged the address to major wallets as a phishing site. Cloudflare labeled the domain as risky and stripped its DNS records, the entries that map a web address to a server. The name stopped pointing anywhere. (and this is the part most people overlook) DNS removal is what actually cut off the phishing page's reach, not any action on the blockchain itself. Once a name stops resolving, the usual route to the fake page closes, but nothing in that step reverses approvals users already signed.

Losses and Open Questions

Blockchain security firm GoPlus Security estimates user losses at $350,000, spread across Ethereum, Arbitrum, Base, BNB Chain, Ink and Plasma. Across hasn't confirmed that figure. Treat it as a working estimate rather than a settled total. Multichain losses are hard to tally cleanly, since each chain has its own explorers and not every victim reports what happened. Across's silence on the number is typical of an incident still under review, but it leaves readers without a yardstick for how big this really was.

The mechanism matters more than the total. According to GoPlus, the fake page convinced users to sign token approvals, which the attacker then used to pull funds. Those included EIP-2612 permits, an Ethereum standard that grants spending rights through an offchain signature, and authorizations for Permit2, a widely used approval contract that lets a single signature authorize transfers from a wallet. The signature can look routine to the person making it, and that's the part worth watching in any phishing incident. A wallet prompt asking for a signature rarely reads like a transfer. Users who would never send funds to a stranger will still approve a message that quietly authorizes exactly that. Signature-based permissions that cost no gas and resemble ordinary login requests are a well-documented pattern in this category of attack, and wallet interfaces have struggled to make their consequences clear at the moment of signing.

Across says visitors who reached across.to before Cloudflare shut the site down "may have been affected." Third-party integrations and developers using its API were not. Anyone hit should message the team with transaction details and revoke any permissions granted to the attacker. Across has said "all affected users will be made whole," but it hasn't explained how. That's a promise without a mechanism, and it deserves the same scrutiny as the security claims. Revoking approvals falls to the user, and plenty of people won't know to do it until someone tells them. If you used the site during that window, check your token approvals now rather than waiting for a reimbursement process that hasn't been described yet.

Namecheap founder Richard Kirkendall responded on X and helped Across secure its account, and the registrar has opened an investigation. Across still hasn't said how the attacker got past the registrar's account protections. That's the question the post-mortem has to answer. If a social engineering attack on a registrar was enough to hand over a protocol's domain, every team that trusts a registrar login with its front end should be asking how well its own vendor's defenses hold up.

Why This Matters Beyond Across

Domain names feel like plumbing, and that's exactly why they get neglected. Most teams treat registration as a yearly renewal rather than a security surface. Yet the domain is the thing that tells a user's browser where to go, and whoever controls it controls the screen people trust before they sign anything. This is more significant than it looks, because a smart contract audit can't protect a user who lands on a convincing clone of the interface.

Registrars typically offer account locks, registry-level protections and multi-factor options, and those controls only help if they're configured and enforced on the accounts that matter most. The gap usually sits in the support process. Recovery and account-change requests often run through human channels, and attackers have long targeted those channels because they're easier to manipulate than cryptographic keys. Whether that's what happened here is still unclear. Across hasn't published the details, and the post-mortem will be the first real evidence.

What should a DeFi team actually do? Start by inventorying every service that can change where your front end points: registrar, DNS provider, CDN, email and any dashboard with admin rights. Then ask who can reach each one, and whether a phone call or a convincing email could get them changed. That's unglamorous work, but it's the kind of work that would have made this incident harder to pull off.

What to Watch Next

The next concrete milestone is the promised post-mortem. It should answer three questions: how the attacker got past the registrar, what Across's own monitoring caught and missed, and how it plans to make affected users whole. Until those answers arrive, the team's confident language about locked-down security reads as a claim, not a finding. And yet the speed of the shutdown, with Cloudflare and SEAL911 moving quickly, suggests the response machinery worked once the attack was visible. The harder question is why it had to be needed at all.