Have you ever clicked through to a familiar crypto site only to feel that something was just a little off? That uneasy second-guess can make all the difference. On November 10, users of Across Protocol found themselves in exactly that situation when attackers seized control of the domain and pointed visitors toward a carefully crafted phishing page. Within hours an estimated $350,000 had moved out of wallets across several networks. The team has now restored the site, yet the episode still leaves a lingering sense of how fragile even established infrastructure can be.
How a Domain Takeover Turned a Trusted Bridge Into a Trap
Across Protocol operates as a cross-chain bridge, moving assets between networks with relative speed and low friction. That convenience is precisely what made the site a valuable target. Around 18:45 UTC on November 10 an unauthorized party gained control of the domain through what the team later described as social engineering aimed at the registrar. No smart-contract exploit was required. The attackers simply altered DNS settings and redirected traffic to a near-perfect copy of the legitimate interface.
I find it striking how quickly the damage can accumulate once that switch is flipped. Within roughly fifteen minutes the protocol team received an alert and began working to cut off the compromised site. Security groups flagged the domain for major wallets, and network-level protections later classified it as dangerous before stripping the DNS records entirely. Still, the window stayed open long enough for determined users to interact with the fraudulent page.
What Users Actually Signed Away
Security researchers later estimated total losses near $350,000 spread across Ethereum, Arbitrum, Base, BNB Chain and two additional networks. The methods were classic yet effective. Visitors who connected wallets were prompted to sign EIP-2612 permits, Permit2 authorizations, or ordinary token approvals. Once granted, those permissions let an attacker-controlled spender move assets without further confirmation from the owner. In a few cases users appear to have sent funds directly.
That is the quiet danger of modern wallet interactions. A single signature can open a standing authorization that survives even after the malicious page disappears. I have seen too many people assume that closing the tab ends the exposure. It does not. Revoking approvals remains the only reliable follow-up step, and even then some off-chain signatures can linger.
All affected users will be made whole. We’ll share a full post-mortem in the coming days.
The protocol’s public statement struck a clear note of responsibility. The team confirmed that API users and third-party integrations remained untouched throughout the incident. Only visitors who landed on the hijacked website during the compromised window faced risk. That distinction matters. It shows the attack surface was limited to the public-facing domain rather than the underlying contracts or backend systems.
Timeline of the Recovery Effort
By the following day the domain had returned to legitimate control. Across announced that every system was operating normally again. The founder of the registrar stepped in publicly, assisting with account recovery and opening an internal investigation. Temporary suspension of the frontend and API had already limited further exposure while the team worked through registrar channels.
Cloudflare’s classification of the domain as dangerous played a useful supporting role. Once DNS records were removed, new visitors could no longer reach the phishing page even if they typed the familiar address. Wallet providers had also begun displaying warnings. Those layered defenses bought critical time, yet they could not reverse permissions already granted or funds already transferred.
Perhaps the most interesting aspect is how ordinary the attack vector looks in hindsight. Social engineering against a domain registrar requires no zero-day exploit or sophisticated smart-contract knowledge. It simply requires enough information and persistence to convince support staff that the request is legitimate. Established security controls on the domain itself proved insufficient once the account behind those controls was compromised.
Comparing This Incident to Earlier Trouble
This November event stands apart from an earlier episode involving the protocol’s Solana relayer. In that case fabricated deposit events totaling tens of millions in claimed value led to a net loss under four million dollars after some attacker funds remained trapped. The July situation targeted operational logic. The November attack targeted the public face of the project and the wallets of anyone who trusted the URL.
Different vectors, same underlying lesson. Infrastructure outside the smart contracts themselves can still create serious exposure. Domain registration, DNS management, and even the human processes that govern those services form part of the overall security perimeter. Ignoring any of those layers leaves an open door.
Practical Steps Every User Should Take Right Now
Anyone who connected a wallet to the Across site on November 10 should treat the interaction as potentially compromised. The protocol itself directed users toward tools that list and revoke outstanding approvals. Doing so stops further transfers under those permissions, although it cannot recover assets already moved.
- Review every token approval granted on the day of the incident
- Revoke any unknown or unexpected spender addresses immediately
- Check transaction history for unexpected outbound transfers
- Contact the official protocol channels only through verified accounts if you believe you were affected
- Watch for lingering browser or wallet warnings that may take time to clear
Some signatures sit outside the usual approval lists. Permit-style authorizations can remain valid even when ordinary token allowances look clean. That is why a careful, manual review of recent activity matters more than a quick glance at a single interface. In my experience the users who move fastest to revoke and document their exposure recover the most peace of mind, even when the protocol later compensates losses.
Why Domain Security Still Feels Like an Afterthought
Bridges and other DeFi front ends attract enormous attention to their contracts and audits. The domain that sits in front of those contracts often receives far less scrutiny. Registrars handle millions of domains. Support processes must balance speed and verification. Attackers understand that tension and exploit it repeatedly.
A similar pattern appeared in other recent website compromises across the sector. Multiple projects saw DNS changes that redirected traffic to phishing kits. The common thread is rarely a novel technical breakthrough. It is usually a successful social-engineering conversation or a compromised credential set. Once the attacker controls the domain, the rest of the operation becomes almost routine.
I keep returning to the same observation. Users cannot reasonably verify the integrity of every domain they visit in real time. They rely on the project teams and the infrastructure providers to maintain that integrity. When that chain breaks, the cost lands on ordinary wallet holders who simply typed a familiar address.
Compensation Promises and the Longer View
Across has stated clearly that affected users will be made whole. That commitment is welcome, yet the details of verification and payout will matter. Users have been asked to supply wallet addresses and transaction hashes through official channels while remaining alert for impersonators. Temporary phishing warnings may continue to appear in browsers and wallets even after the legitimate site returns. Patience will be required on both sides.
Looking further ahead, the incident will likely accelerate conversations about registrar-level protections, multi-factor requirements for domain changes, and perhaps even on-chain domain alternatives. None of those solutions are perfect, and each introduces its own trade-offs. Still, the status quo leaves too much surface area exposed.
Volume data shows Across processed several billion dollars in transfers over the preceding month. Scale of that magnitude makes the project an attractive target. It also means that even a relatively modest $350,000 loss draws attention far beyond the immediate victims. Every successful phishing episode chips away at the broader perception of safety in cross-chain activity.
Lessons That Extend Beyond One Protocol
What stands out most is the speed of the response once the team recognized the problem. Fifteen minutes from alert to active mitigation is respectable by any measure. Layered defenses from security groups and infrastructure providers then contained the damage. Those elements worked. The failure occurred earlier, at the point where human processes around domain ownership proved weaker than the technical controls surrounding the contracts.
Users can reduce personal risk by treating every connection request with fresh skepticism, maintaining separate wallets for different activities, and reviewing approvals on a regular schedule rather than only after an incident. Projects can reduce collective risk by treating domain accounts with the same seriousness they apply to multisig keys and admin privileges. Registrars can tighten verification steps without creating unbearable friction for legitimate owners.
None of those improvements will eliminate phishing entirely. Social engineering adapts. Yet each layer of friction raises the cost for attackers and shrinks the window of opportunity. In a space that moves billions daily, even small reductions in successful attacks translate into meaningful protection for ordinary participants.
Where the Story Goes From Here
Across has promised a detailed post-mortem. That document should clarify exactly how the social-engineering attempt succeeded and which additional controls the team intends to put in place. Transparency on those points will matter more than any single compensation payment. Users and other protocols will watch closely for practical recommendations that can be adopted more broadly.
In the meantime the restored site continues normal operations. API and third-party services never left service. The public frontend is once again under legitimate control. For the individuals who interacted during the compromised hours, the practical work of reviewing and revoking permissions remains the immediate priority.
I keep thinking about how ordinary the entire sequence feels once the details settle. A familiar URL. A convincing interface. A few signatures that seemed routine. Then the quiet realization that funds had moved. That pattern has repeated across the industry more times than most of us care to count. Each new instance serves as another reminder that the weakest link is often the one we stop examining closely because it has always worked before.
Domain ownership, registrar processes, and the human conversations that govern both deserve the same ongoing attention that contracts and audits already receive. Until that happens, the next phishing page is only a successful support ticket away. Across Protocol has restored its site and committed to making users whole. The deeper question is whether the wider ecosystem will treat the underlying vulnerability with equal seriousness before the next window opens.
The estimated losses remain modest relative to total bridge volume, yet the episode still illustrates a persistent gap between technical sophistication and operational hygiene. Users who treat every wallet connection as potentially hostile, who maintain clean approval lists, and who verify domains through secondary channels will sleep better regardless of which project appears in the next headline. Projects that harden their registrar accounts and communicate rapidly during incidents will retain more trust when the inevitable next attempt arrives.
Across has taken the first necessary steps. Full restoration, clear communication, and a public commitment to compensation form a solid foundation. The coming post-mortem will determine whether the industry extracts lasting lessons or simply files the event under another temporary inconvenience. For anyone who moves assets across chains, the practical response is straightforward. Review permissions. Question familiar interfaces. Assume the domain can be taken until proven otherwise. Those habits cost little and protect a great deal.
In the end the story is less about one protocol and more about the shared infrastructure every bridge, exchange, and frontend relies upon. When that infrastructure bends, the cost lands on individual wallets first. Making those wallets whole is the right immediate action. Closing the gaps that allowed the bend is the longer, harder, and ultimately more important task.
