Curve Front-End DNS Hijacking (Aug 2022)

introduction

FRONT-END SUPPLY CHAIN ATTACK

Incident Overview

On August 9, 2022, the curve.fi front-end was compromised via a DNS hijacking attack, redirecting users to a malicious clone that drained wallets through a fraudulent approval transaction.

The Curve Finance front-end domain (curve.fi) suffered a DNS cache poisoning attack targeting its nameserver. The attacker gained control of the domain's DNS records and redirected users to a cloned website hosted on a different IP address. The malicious front-end was a near-perfect replica of the legitimate Curve interface, designed to socially engineer users into signing a single, high-value token approval.

The attack vector exploited the trust relationship between the user, the DNS system, and the smart contract interface. The cloned site prompted users to approve a malicious contract address (0x9eb5...) that was obfuscated to appear as a legitimate Curve pool contract. Once the approval transaction was signed, the attacker could invoke transferFrom to drain the approved token from the victim's wallet. The protocol's smart contracts on-chain remained uncompromised; the attack was entirely a Web2 infrastructure and user-interface integrity failure.

The Curve team's emergency response included working with the nameserver provider to restore correct DNS records and disseminating warnings across social channels. The incident highlights the critical dependency of DeFi protocols on DNS security and the need for wallet-level transaction simulation and domain verification. For teams building on or integrating with Curve, this event underscores the necessity of verifying on-chain contract addresses independently of any front-end and implementing robust phishing detection for approval transactions.

CURVE.FI DNS HIJACKING

Incident Quick Facts

Operational timeline and impact assessment of the August 2022 front-end attack that redirected users to a malicious clone, resulting in wallet-draining approval transactions.

Phase	Signal	Response	Owner
Attack vector	DNS nameserver for curve.fi was compromised via a social engineering attack on the registrar (iWantMyName), allowing the attacker to redirect the A record to a malicious IP.	Verify that your domain registrar supports advanced security features like hardware MFA and lock-down modes. Audit DNS change notification processes.	Front-end security teams, DevOps
Malicious payload	A cloned Curve UI prompted users to approve a malicious contract (0x9eb...), which drained approved tokens via transferFrom.	Wallets and interfaces should simulate transactions and clearly display the token approval amount and spender address, not just the origin domain.	Wallet developers, UI/UX teams
User impact	Users who visited curve.fi during the attack window and approved the malicious transaction had tokens drained from their wallets.	Affected users should revoke approvals to the malicious contract immediately. Security teams should monitor for similar cloned-UI approval phishing patterns.	End users, wallet security teams, exchange security
Incident detection	The attack was detected by community members and security researchers who noticed the malicious contract and DNS redirection.	Establish automated monitoring for DNS record changes and front-end code integrity (CSP, SRI) for all critical DeFi front-ends.	Protocol operations, security researchers
Containment	The Curve team regained control of the DNS and pointed it back to the legitimate front-end. The malicious clone was taken down.	Prepare an incident response playbook for DNS hijacking that includes registrar contact procedures, DNS propagation acceleration, and user communication templates.	Protocol core team, DevOps
Root cause	The domain registrar's account security was the single point of failure. No 2FA or advanced security was enforced on the registrar account.	Migrate critical protocol domains to registrars with hardware MFA, multi-person approval for changes, and registry lock capabilities.	Protocol governance, security operations
Long-tail risk	Users who did not revoke the malicious approval remain at risk of future drainage if the attacker retains control of the drainer contract.	Publish a public revocation guide and maintain a persistent warning. Integrate approval-checking tools into the official UI.	Protocol front-end team, wallet providers

technical-context

FRONT-END SUPPLY CHAIN ATTACK

Attack Vector: Nameserver Compromise and DNS Poisoning

Analysis of the DNS hijacking attack vector used against curve.fi, which redirected users to a malicious clone to drain wallets via fraudulent approval transactions.

The August 2022 attack on the Curve front-end was not a smart contract exploit but a Web2 infrastructure compromise targeting the protocol's DNS provider. The attacker gained unauthorized access to Curve's nameserver, modifying the DNS A record for curve.fi to point to a server under their control. This DNS poisoning attack meant that users typing the legitimate URL into their browser were transparently redirected to a malicious clone of the Curve interface, with no visible indication of compromise in the browser's address bar.

The cloned site was a sophisticated social engineering tool. It replicated the Curve UI but injected a malicious transaction into the user's workflow. When a victim attempted a routine operation like a swap, the site prompted a standard approve transaction. However, this transaction granted spending approval not to the legitimate Curve router contract, but to a malicious attacker-controlled contract address. Once approved, a separate transaction drained the approved token from the victim's wallet. The core protocol's smart contracts remained secure; the attack vector was entirely at the user-interface layer, exploiting the trust users place in a familiar domain name.

This incident underscores that a protocol's security perimeter extends far beyond its on-chain code to include DNS management, domain registrar accounts, and front-end hosting infrastructure. For operators and builders, the key hardening measures include migrating to registrars with strong multi-factor authentication, implementing DNSSEC to cryptographically sign DNS records, and using a multi-provider DNS strategy to prevent a single point of failure. For wallets and integrators, the attack highlights the critical need for transaction simulation and clear, human-readable approval prompts that display the target contract address and token amount, enabling users to detect anomalies even when the front-end is compromised.

IMPACTED PARTIES AND OPERATIONAL RISK

Affected Systems and Actors

Direct Victims

Any user who visited the curve.fi domain during the attack window and interacted with the malicious clone was directly at risk. The cloned UI was a near-perfect replica, making visual detection extremely difficult.

Attack Mechanics

The malicious site prompted users to approve a token-spending transaction. Instead of a standard Curve router, the approval was granted to a wallet-draining contract. Once approved, the attacker could transfer the approved token from the user's wallet at any time.

Immediate Actions

Revoke approvals: Users must immediately check and revoke any approvals granted to the malicious contract address.
Asset relocation: For high-value wallets, consider moving funds to a new, uncompromised address as a precaution.
Bookmark verification: Always verify the correct Curve URL and use bookmarks instead of search engines to navigate to DeFi front-ends.

implementation-impact

FRONT-END SUPPLY CHAIN ATTACK ANALYSIS

Security Control Failures and Lessons

The August 2022 curve.fi DNS hijack exposed critical gaps in Web3 front-end security. This analysis breaks down the specific control failures, the attacker's social engineering, and the actionable mitigations for wallet, UI, and infrastructure teams.

DNS Infrastructure Compromise

The attacker gained control of curve.fi's domain by compromising its nameserver at iwantmyname. They altered the DNS records to point the legitimate domain to a malicious server. This bypassed all on-chain security and targeted the weakest link in the user interaction pipeline: the resolution of a human-readable name to a server IP. Teams must treat DNS management as a critical security perimeter, enforcing strict access controls, multi-person approval, and registrar locking.

Malicious Clone UI and Social Engineering

The cloned site was a near-perfect replica of the Curve interface. It simulated a standard token approval flow but prompted users to approve a malicious contract that drained their wallets. The attack exploited the user's trained behavior of approving transactions without manual inspection of the calldata. This highlights the need for wallets to parse and clearly display the consequences of an approval, not just the raw transaction data.

Approval-Based Draining Mechanism

The malicious contract relied on the approve function to gain control over user assets. Once a user signed the approval, the attacker could call transferFrom to drain the specified token. This is a fundamental risk in the ERC-20 standard. Mitigations include using increaseAllowance/decreaseAllowance patterns, setting approvals to exact required amounts, and regularly revoking stale approvals via tools like revoke.cash.

Incident Response and Communication

The Curve team quickly identified the attack, warned users via Twitter and other channels, and worked to regain control of the domain. However, the initial communication was fragmented across social platforms, a single point of failure for security advisories. Protocols should establish a dedicated, verifiable security communication channel (e.g., a status page on IPFS, a signed on-chain registry) that is independent of the compromised DNS infrastructure.

Wallet-Level Defense-in-Depth

This incident proves that smart contract security is insufficient. Wallets are the last line of defense. They must implement domain binding, where a dApp's canonical contract addresses are verified against a community-maintained registry. Wallets should also simulate transactions against a local fork to show the user the expected balance changes before they sign, making approval-draining attacks visibly obvious.

DNS Security Posture for Web3

The attack vector was not a smart contract bug but a failure in traditional internet infrastructure. Web3 front-ends must adopt DNS security extensions (DNSSEC) and consider decentralized naming alternatives like ENS with IPFS/Skynet hosting for critical interfaces. A robust security posture requires a multi-layered approach: registrar account security, DNSSEC signing, and a verifiable, decentralized fallback for the user interface.

CURVE.FI DNS HIJACKING INCIDENT ANALYSIS

Risk Matrix: Front-End and DNS Attack Surface

Evaluates the attack surface, failure modes, and affected parties in the August 2022 curve.fi DNS hijacking that redirected users to a malicious clone site for wallet draining.

Risk Area	Failure Mode	Who is Affected	Mitigation and Action
Domain Registrar Security	Compromised registrar account allowed attacker to alter nameserver records for curve.fi, redirecting DNS resolution.	All front-end users; Curve operations team; protocols relying on curve.fi for price checks.	Verify registrar account security: enforce hardware MFA, remove phone-based recovery, and lock nameserver changes.
DNS Nameserver Integrity	Attacker pointed the domain to a malicious nameserver, serving a cloned UI with no visible difference from the legitimate site.	Wallets and users performing swaps or approvals; any service using the front-end as a canonical interface.	Monitor DNS records continuously; implement DNSSEC; operators should run independent DNS resolution checks against a trusted resolver.
Malicious Contract Approval	Cloned UI prompted users to approve a token-spending contract controlled by the attacker, draining wallets that signed the transaction.	Users who approved the malicious contract; wallets that do not simulate or decode approval transactions clearly.	Wallet teams must improve transaction simulation and human-readable approval warnings. Users must verify contract addresses against a known allowlist.
Front-End Clone Fidelity	The malicious site was an exact replica of the legitimate Curve UI, making visual detection nearly impossible for end users.	All users who rely on visual trust of the UI; security auditors evaluating Web3 phishing risks.	Integrate subresource integrity checks; deploy IPFS/ENS-backed mirrors; use wallet-based domain verification to flag mismatches.
Emergency Response Coordination	Initial response required coordination between the Curve team, registrar, and nameserver provider to regain control and propagate corrected records.	Curve operations team; exchanges and aggregators that paused Curve interactions; LPs exposed during the incident window.	Pre-establish an incident response plan with registrar and DNS provider contacts. Define communication channels for exchanges and major integrators.
Protocol-Level Trust Assumptions	The incident exploited trust in the front-end, not a smart-contract vulnerability, bypassing all on-chain security assumptions.	Protocol architects and security teams who assume front-end integrity is separate from protocol security.	Treat front-end and DNS infrastructure as critical protocol security components. Subject them to the same review rigor as smart contracts.
Downstream Protocol Contagion	Protocols that integrate curve.fi via front-end dependencies or manual price checks could have been indirectly affected by the malicious UI.	Yield aggregators, lending protocols, and dashboards that rely on the curve.fi front-end for data or user actions.	Integrators should use on-chain data sources and contract calls directly, not front-end scraping. Verify the integrity of any off-chain dependency.

DNS HIJACKING RESPONSE ANALYSIS

Incident Timeline and Response

A structured breakdown of the operational timeline and response actions taken during the August 2022 curve.fi DNS hijacking. This analysis maps the attack lifecycle from initial compromise through user impact, emergency containment, and long-term remediation, providing a model for front-end security incident response.

The incident originated from a compromise of Curve's DNS registrar, Iwantmyname, via a social engineering attack that bypassed 2FA. The attacker altered the nameserver records for curve.fi to point to a malicious server they controlled.

What to check:

Verify that your domain's registrar uses hardware security keys (FIDO2/WebAuthn) and not just TOTP-based 2FA.
Audit the registrar's account recovery and support processes. The attacker exploited a human in the loop.
Confirm that DNSSEC was not enabled for curve.fi at the time, which would have prevented the redirection.

Why it matters: This attack completely bypassed Curve's own infrastructure. No server at Curve was breached. The entire attack surface was the third-party registrar's customer support workflow.

resource-links

INCIDENT SOURCES

Canonical Resources and Post-Mortems

Use these resources to reconstruct the August 2022 curve.fi DNS hijacking, validate affected user flows, and harden wallet, front-end, and domain-control procedures before the next Web3 phishing event.

Curve official incident communications

Start with Curve’s official communication channels when building an incident timeline. For the August 2022 DNS hijacking, the critical operational facts were not changes to Curve pool contracts but the compromise of the curve.fi resolution path and redirection to a malicious clone UI. Security teams should archive the relevant Curve posts, compare them with internal alert timestamps, and separate official recovery guidance from third-party speculation. Treat social posts as incident evidence, not as a substitute for your own DNS, wallet-approval, and transaction-level review.

EXPLORE

Legitimate Curve documentation and repositories

Use Curve’s documentation and GitHub organization as the baseline for legitimate integration behavior, contract interfaces, and front-end assumptions. The DNS hijack exploited user trust in the web entry point rather than a Curve AMM invariant or gauge bug, so teams should verify which contracts their wallet flows actually invoked and whether the UI presented by the browser matched known Curve code paths. Integrators should not rely only on domain trust; pin expected contract addresses, chain IDs, ABI selectors, and transaction simulation outputs where possible.

EXPLORE

On-chain trace reconstruction

Reconstruct the malicious approval and drain path directly from Ethereum transaction data. Analysts should identify the phishing contract or spender addresses from trusted incident sources, enumerate approvals granted during the exposure window, and trace subsequent token transfers rather than assuming every Curve user was affected. This is especially important for custodians, wallets, and risk desks that need account-level exposure lists. Use block explorer evidence alongside wallet logs and RPC provider records so the post-mortem distinguishes users who only visited the cloned site from users who signed harmful approval transactions.

EXPLORE

Approval revocation workflow

Any user or treasury that interacted with the spoofed Curve front end during the incident window should be reviewed for abnormal token approvals. The key remediation is not pool withdrawal by default; it is identifying and revoking approvals to malicious spenders or rotating operational wallets where risk cannot be bounded. Wallet teams should surface spender name, destination contract, token, allowance size, and chain before asking users to sign revocations. Exchanges and funds should preserve signed-transaction evidence for later claims, compliance review, or law-enforcement reporting.

EXPLORE

DNS and domain-control evidence package

The post-mortem should include DNS-provider logs, registrar events, nameserver changes, TTL behavior, DNSSEC status, certificate transparency observations, CDN logs, and any emergency domain failover actions. For a front-end DNS incident, these artifacts are as important as smart-contract traces because they explain why users reached a malicious clone while core Curve contracts remained unchanged. Protocol front-end teams should retain this evidence in a structured format and test whether monitoring would have detected unauthorized NS, A, CNAME, or certificate changes before users signed transactions.

Internal readiness review after the incident

Use the Curve DNS hijacking as a control test for your own protocol, wallet, or aggregator. Confirm that production domains require hardware-key protected registrar access, least-privilege DNS roles, registry lock where available, monitored nameserver changes, transaction simulation, spender reputation checks, and emergency user messaging that does not depend on the compromised domain. Chainscore Labs can help teams turn the public incident record into an implementation checklist, review front-end trust boundaries, and validate monitoring coverage for DNS, wallet approvals, and malicious contract interaction patterns.

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

DNS HIJACKING INCIDENT FAQ

Frequently Asked Questions

Operational and security-focused questions for teams assessing their exposure, response protocols, and preventive controls following the curve.fi front-end compromise.

The DNS nameserver for curve.fi was compromised, allowing an attacker to redirect the domain's A record to a malicious IP address. Users visiting the genuine URL were served a cloned Curve front-end that was visually identical to the legitimate interface. The malicious UI prompted users to approve a token-spending transaction that drained approved assets to an attacker-controlled address. The core Curve smart contracts on-chain were not compromised; the attack was purely a front-end and user-interface supply-chain attack exploiting DNS infrastructure.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Curve Front-End DNS Hijacking (August 2022)

Incident Overview

Incident Quick Facts

Attack Vector: Nameserver Compromise and DNS Poisoning

Affected Systems and Actors

Direct Victims

Attack Mechanics

Immediate Actions