Starting late on October 30 (US Eastern time), several DeFi projects whose domains are registered with Name.com had their websites redirected without authorization. Users typed the correct address and landed on attacker-run copies. According to security researchers, those pages served a wallet drainer that tricked visitors into signing approvals.
Name.com confirmed 15 customer domains were affected, says all have been restored, and is investigating. Vercel says 10 of them were associated with its platform. The projects used different DNS providers; what they shared was the registrar. Independent estimates put on-chain losses at roughly $140K to $200K, excluding Solana and Aptos. How the attacker gained the ability to change the domains has not been disclosed.
Where small teams are exposed
Process
Domains are often registered by a founder years ago with a personal email. Renewals and DNS changes go unreviewed, and nobody watches whether records change. The website, docs and app download page all hang off that one domain.
Risk
An attack like this does not need to break the project's own frontend code, servers or contracts, and users still get drained. Users trust the address bar. Once the domain points elsewhere, every other control is invisible to them, and the team is left with reimbursements and lost trust.
Privileges
Whoever controls the registrar account can change the nameservers, which means deciding what every user sees. That account's login, recovery email and API keys deserve the same protection as production servers.
Five things you can do now
- Log in to your registrar and confirm the nameservers and key DNS records match what you expect. Turn on transfer lock, and request a registry lock for your main domain if your registrar offers it
- Move the registrar account to a company email with a hardware security key (or at least app-based 2FA). Retire personal accounts and remove unused API keys and extra users
- Monitor nameservers, A/CNAME records and certificate issuance for your main domains, and alert the on-call channel on any change
- Write a "website hijacked" playbook in advance: who posts the warning on X and in your community, who calls the registrar and DNS provider, and how to take the frontend offline fast
- In your dApp, prompt users to check what they are approving, and steer large actions toward wallets that show full transaction details
The number of affected domains and their restoration come from Name.com's statement and Vercel's security bulletin. Losses are independent on-chain estimates that use different methods. How the attacker gained the ability to change the domains has not been disclosed, and this article does not speculate. This article does not cover attack details.
