The registrar says all affected domains are back, but a wallet drainer campaign reportedly took approximately $138,000 from users first
Name.com says hackers hijacked 15 customer domains, including 10 tied to Vercel. All of the affected domains have now been restored.
That is the good news. The less good news is that the hijacked addresses reportedly sent crypto users to malicious pages built to empty their wallets.
The campaign ran between October 30 and 31, 2026. It hit at least 12 decentralized finance project websites, and estimates put the on-chain losses at approximately $138,000.
How the attack worked
Think of a domain name as the address on a storefront sign. DNS is the system that tells your browser which building that sign actually points to.
If someone gets into the registrar, the company that manages those records, they can quietly swap the building. The sign looks the same. You walk in anyway.
That is roughly what happened here. Visitors typed familiar DeFi URLs and landed on lookalike pages under attacker control.
Those pages ran a tool known as the Step Drainer. It tricked users into signing transactions they did not intend to approve, which then drained their wallets.
That distinction matters. The smart contracts behind the targeted projects stayed intact and uncompromised throughout the incident.
Every targeted domain was registered through Name.com. Registry records show that ten domains were placed on ‘client hold’ status before being restored, a status that temporarily stops a domain from resolving at all.
Who confirmed what
Name.com publicly acknowledged that domains had been improperly redirected. Alongside restoring them, the registrar told customers to review their DNS settings and turn on two-factor authentication.
DeFi projects Flap and Kintsu confirmed the attacks happened at the registrar level. Security firm Blockaid did the same.
Some teams managed to limit the damage by moving their nameservers to hosting services like Vercel or Cloudflare.
Exactly how the attackers got into the registrar layer remains unknown. Investigators are still working to pin down the entry points.
Why the front end keeps being the weak spot
DeFi likes to talk about trustless systems. Code is law, contracts are immutable, and no middleman can freeze your funds.
The website you use to reach that code, though, still runs on decidedly old-school internet plumbing. Domain registrars, DNS records and account logins sit squarely in the middle.
This incident is a clean example of that gap. The contracts did their job perfectly, and users still lost money.
Security people call this a supply-chain attack. Instead of hitting the target directly, attackers compromise a shared vendor that many targets rely on.
What this means for DeFi teams and users
For users, the dollar figure is modest by crypto-hack standards. Approximately $138,000 is not a nine-figure bridge exploit.
The more uncomfortable point is how little a careful user could have done. The URL was correct, and the page looked right. The only real defense was reading the transaction prompt closely before signing it.
That puts renewed weight on wallet-level warnings and transaction simulation. Blockaid’s involvement in confirming the attack is a reminder that this tooling increasingly sits between users and a bad signature.
For project teams, the lesson is less about code audits and more about operational hygiene. Name.com’s own advice, checking DNS settings and enabling two-factor authentication, is basic, but basics are what failed somewhere in this chain.
The teams that moved nameservers quickly appear to have fared better. That suggests incident response plans should include a registrar playbook, not only a smart contract pause button.
The open question is the root cause. Whether this was a compromised internal system, stolen customer credentials or something else will shape how seriously other registrars and their crypto clients need to respond.
Until investigators answer that, DeFi teams relying on any single registrar may want to treat their domain account with the same paranoia they reserve for their deployer keys.
