Hackers have hijacked approximately a dozen DeFi protocol websites and drained roughly $138,000 from users who interacted with the compromised front ends. Every affected site shared one common detail: its domain was registered through Name.com. The incident is a direct reminder that the trust surface of a DeFi protocol extends well beyond its smart contracts to the web infrastructure serving its user interface.

What is known about the DeFi website hijacks

According to reporting from The Block on October 31, 2026, attackers gained control of roughly twelve DeFi websites and redirected users into malicious flows that resulted in approximately $138,000 in stolen funds.

The confirmed facts remain narrow: approximately twelve DeFi websites were affected, all registered through Name.com, and approximately $138,000 in user funds was stolen. The specific protocols targeted, the precise attack vector, and the number of individual victims have not been confirmed in available reporting. Shared registration alone does not establish causation, and Name.com has not been confirmed as the direct point of failure.

What remains unconfirmed

According to unconfirmed reports, the shared Name.com registration may point to a credential compromise or account takeover at the registrar level, which would have allowed attackers to modify DNS records and redirect domain traffic without touching the underlying smart contracts. The incident may equally have involved compromised registrar accounts, social engineering, or another vector entirely.

The distinction matters for both affected users and protocol teams: if DNS records were tampered with, the on-chain smart contracts themselves may be unaffected, meaning protocol treasuries and liquidity pools could remain intact while users who interacted with the spoofed front ends bore the losses.

Front-end hijacks routed through domain infrastructure have precedent in the sector: in 2022, attackers redirected the DNS for Curve Finance to a malicious clone of its interface after compromising a domain provider account, a widely cited episode that put registrar and DNS controls on DeFi teams' security checklists. Precedent is not evidence, though — whether the shared Name.com registration in this case was central or incidental can only be settled by the affected teams' own incident findings.

How a hijacked DeFi website puts users at risk

A web front-end compromise is structurally different from a smart contract exploit. When attackers control a domain, they can serve a visually identical copy of the legitimate interface while silently substituting wallet connection endpoints, contract addresses, or transaction calldata. A user signing what appears to be a routine approval may in fact be authorizing a drainer contract to sweep their entire token balance.

What users should verify before signing any transaction

Before connecting a wallet or signing any transaction on a DeFi interface, users should independently verify the contract address being interacted with against the protocol's official documentation, not just the URL in the browser. The Secure Transaction Verification and Authorization (STVA) framework covers the specific steps for inspecting calldata before approval. A domain that resolves correctly and displays a valid SSL certificate does not guarantee the front end has not been tampered with at the DNS or hosting layer.

Phishing-resistant hardware wallets can display transaction details on the device screen, independent of the browser, giving users a second verification layer. Even so, a determined attacker who controls the front end can craft misleading transaction descriptions. The only reliable protection is verifying the destination contract address against the protocol's canonical on-chain deployment, sourced from the official GitHub repository or governance documentation rather than the connected dApp interface.

Token approvals granted to a compromised contract persist on-chain until explicitly revoked. Any user who connected a wallet and signed a transaction during the window these sites were under attacker control should treat outstanding approvals as potentially malicious. Approval management tools allow users to audit and revoke permissions across ERC-20 tokens, but only after independently confirming the correct contract addresses to revoke and the correct network to operate on.

What users and DeFi teams should do next

User actions

Users who interacted with any of the affected DeFi websites should first avoid connecting wallets or signing new transactions until the relevant protocol publicly confirms that the front end has been restored and verified. Official communications should be sourced from the protocol's verified social accounts and governance forums, not from links embedded in direct messages or community chat messages, which are a common secondary attack vector following a front-end compromise. Because available reporting has not named the affected protocols, users of any DeFi front end should watch for direct announcements from the protocols they use rather than assume they were unaffected.

For users who did sign transactions during the incident window, revoking approvals is advisable only after confirming the correct malicious contract address from a verified, independent source. Revoking the wrong contract wastes gas and provides false assurance. Protocols such as Aave V4 publish canonical contract registries that can serve as a reference point for distinguishing legitimate protocol contracts from attacker-deployed drainers.

Protocol team response

Affected teams should treat this as an active incident until the full attack chain is confirmed. Immediate priorities include auditing domain registrar account access logs, rotating all credentials associated with Name.com accounts, verifying current DNS records against known-good snapshots, and checking HTTPS certificate transparency logs for any unauthorized certificates issued during the attack window.

Teams should also preserve all incident evidence before making changes, as forensic data about the attack window — including DNS change logs and any communication with the registrar — will be needed to establish exactly what was compromised and when. Publishing a clear, timestamped incident report once the attack vector is confirmed, rather than issuing speculative communications during the investigation, is the standard affected communities will expect.

Domain registrar account security, including two-factor authentication enforcement and registrar-level domain locks, is a basic hardening step that prevents unauthorized DNS modifications even when attacker credentials are valid. Domain locking prevents transfers and DNS changes without explicit registrar confirmation, making it a meaningful control for any protocol whose website represents a user-facing trust surface for transactions involving real funds.

The broader lesson

The $138,000 loss reported across roughly a dozen protocols is modest relative to total DeFi TVL on Ethereum. But the structural vulnerability it exposes — namely, that a web2 registrar account can become the weakest link in a protocol's security stack — applies to any DeFi project that relies on a centrally registered domain to serve its user interface. Front-end security, including DNS monitoring, registrar account hardening, and user guidance on independent contract verification, deserves the same operational rigor applied to smart contract auditing.